Re: libpq_r - Mailing list pgsql-hackers

From Lee Kindness
Subject Re: libpq_r
Date
Msg-id 16159.60953.52716.283825@kelvin.csl.co.uk
Whole thread Raw
In response to Re: libpq_r  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: libpq_r  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re:
Next
From: Bruce Momjian
Date:
Subject: Re: