Tom Lane writes:> Lee Kindness <lkindness@csl.co.uk> writes:> > Tom Lane writes:> >>> Okay, so it seems -D_REENTRANT is
theappropriate fix.> > However, _REENTRANT is not a Solarisism... On all (recent) UNIX> > systems it toggles on correct
handlingfor thread specific instances> > of historically global variables (eg errno). It should be considered> > for
allplatforms if libpq is intended to be used from threaded> > programs.> Now that I think about it, what that macro is
probablyreally doing is> switching the code from looking at a static "errno" variable to looking> at a per-thread
variable. So in fact -D_REENTRANT would be correct if> you intended to link with a thread-aware libc, and wrong if you
intended>to link with a non-aware libc. (Is there such a thing as a non-threaded> implementation of libc on the
platformswhere -D_REENTRANT does> anything?) If this analysis is right then I think we should *not*> force _REENTRANT;
itwill have to be up to users to choose the mechanism> they want to use in their programs.
I think in the long-term the libraries are going to have to be looked
at in detail to ensure they work as would be expected from
multithreaded programs. I cannot see any harm in adding -D_REENTRANT
to CFLAGS even though some platforms supersede it with -lthread or
something (becaue they still define _REENTRANT behind the scenes).
I remember in the past reading in detail the issues involved with
making shared libraries work as expected from threads. However I
no-longer has access to that book, but think it was "Multithreaded
Programming with Pthreads"...
Again, something i'd like to look at later this month. Workwise the
threaded code we had which used embedded SQL calls in C fell into
heaps when moved from Ingres to PostgreSQL. And Ingres's ESQL/C is
real crap for threading and we employeed loads of mutexes... So, ...
Lee.