Re: libpq_r

Bruce Momjian writes:
> Lee Kindness wrote:
> > Guys, take a look at what was done in libpq to make it
> > thread-safe... No locks! No overheaded - just using "proper" reentrant
> > functions...
> > If we have libpq_r then we're making a complete hash of it all - being
> > reentrant is good, even if you're not using threads!
> > Now, ecpg is another issue...
> I think the issue is that using a threaded library to link into libpq
> could have locking stuff.
>
> 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 - it's just a normal
shared library, it has has no thread voodoo! A threaded app/library
using libpq doesn't have to do anything special... libpq doesn't need
link the threads library (and it explicitly should not) - only define
_REENTRANT.

The reentrant calls libpq may be using are in the standard system
libraries (not the system thread library), the same libraries that the
app/libs will be linked against.

Now, libecpg on the otherhand does need mutex locks compiled in. Thus
if this is enabled then anyone who links against it also needs to link
in threads (unless the system is "intelligent" like Solaris and
includes empty stubs of the thread functions in libc).

However in this day and age the overhead of the locks are negligible
and it is more desirable to have one library...

L.