Re: [Slony1-general] Thread-safety detection on HP-UX
От | Jan Wieck |
---|---|
Тема | Re: [Slony1-general] Thread-safety detection on HP-UX |
Дата | |
Msg-id | 417F17F8.3040006@Yahoo.com обсуждение исходный текст |
Ответ на | Re: [Slony1-general] Thread-safety detection on HP-UX (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-bugs |
On 10/26/2004 6:13 PM, Bruce Momjian wrote: > I believe Slony always needs threading, it just can be used even if the > OS doesn't fully support all thread-safe functions, so on 8.0 you use > --thread_safety_force. Jan, is that correct? Yes. Slony allways uses pthreads and therefore it requires that on platforms, where the reentrant libc has a different definition for several global symbols (like errno), libpq is compiled with pthread compiler flags. If that actually leads to a "thread-safe" libpq or not is completely irrelevant, because Slony does not need the libpq to be thread-safe. A good example for what happens is Solaris. If libpq is compiled without -pthreads, then "errno" is just the good old "extern int errno;". But if it is compiled with -pthreads, then "errno" is #defined to dereferencing the result of a function, like "*(__thread_errno())" and that function returns the thread specific error variable and int*. Since slon is compiled with pthreads, it links against the reentrant libc which places error codes in the thread specific error variable. Why in devils name that reentrant libc also has a global errno variable at all is a secret to me and probably the last developer who knew that has left Sun 5 years ago, but it has one and leaves it just zero all the time. Since it has one, the extern reference errno from the non -pthread compiled libpq is resolved just fine ... to a location of 4 wasted, meaningless bytes. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-bugs по дате отправления: