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. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html