Re: libpq_r

Поиск
Список
Период
Сортировка
От Lee Kindness
Тема Re: libpq_r
Дата
Msg-id 16159.60953.52716.283825@kelvin.csl.co.uk
обсуждение исходный текст
Ответ на Re: libpq_r  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: libpq_r  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Tom Lane writes:> Lee Kindness <lkindness@csl.co.uk> writes:> > Bruce Momjian writes:> >>> My guess is that if the OS
hasseparate threaded libs, we have to mimic> >>> that stuff.> > But there are NO thread primitives/calls in libpq >
That'snot the point.  The point is stuff that isn't necessarily visible> in the source code --- such as what method it
usesto get at "errno",> whether it's linked to thread-safe versions of malloc and other libc> routines, etc.> If the OS
suppliesboth libc and libc_r, it is unlikely to be a good> idea to link a threaded libpq with libc, or a non-threaded
libpqwith> libc_r.
 

No, that is the point exactly... I know fine well the visibility of
errno and the different ways it may be implemented. You'll find it
hard to come across an OS which doesn't "do the right thing" WRT to
using reentrant functions and "wrappers" if _REENTRANT is defined
during the compile...

That is ALL that is needed, lets not complicate the issue...

And what do you mean by "threaded libpq" and "non-threaded libpq" - as
I say above there are NO thread primitives being used in libpq. It's
just clean reentrant code... This change/patch should be done
irregardless of the move to thread safety!

L.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re:
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: