Re: libpq_r

Tom Lane writes:
> Lee Kindness <lkindness(at)csl(dot)co(dot)uk> writes:
> > Bruce Momjian writes:
> >>> My guess is that if the OS has separate threaded libs, we have to mimic
> >>> that stuff.
> > But there are NO thread primitives/calls in libpq
> That's not the point. The point is stuff that isn't necessarily visible
> in the source code --- such as what method it uses to get at "errno",
> whether it's linked to thread-safe versions of malloc and other libc
> routines, etc.
> If the OS supplies both libc and libc_r, it is unlikely to be a good
> idea to link a threaded libpq with libc, or a non-threaded libpq with
> 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.