Re: libpq thread safety - Mailing list pgsql-hackers

Manfred Spraul wrote:
> Tom Lane wrote:
> 
> >Wait a minute.  I am *not* buying into any proposal that we need to
> >support ENABLE_THREAD_SAFETY on machines where libc is not thread-safe.
> >We have other things to do than adopt an open-ended commitment to work
> >around threading bugs on obsolete platforms.  I don't believe that any
> >sane application programmer is going to try to implement a
> >multi-threaded app on such a platform anyway.
> >
> I'd agree - convince Bruce and I'll replace the mutexes in thread.c with 
> #error. But I think libpq should support a mutex around kerberos (or at 
> least fail at runtime) - right now it's too easy to corrupt the kerberos 
> authentication state.

Let me tell you where I think we are with this thread stuff, when we can
discuss where to go from here.

I think we are doing well with 7.4.X on threads.  All platforms that
have asked for threads have it working with minimal fuss, and I have
gotten help on various OS/compiler combinations.  We don't have any
outstanding thread issues except the unreliable ignoring if send
SIGPIPE, but that only happens on a backend crash, which hopefully
doesn't happen too often, and we have that fixed in CVS.

Now, were do we need to go?  Right now we have a very course
NEED_REENTRANT_FUNCS variable that says either all libc functions we
call are thread-safe, or they are not.  (See src/tools/thread for the
test program.)  However, we really have two types of function tested. 
The first, strerror, can be thread safe by using thread-local storage
_or_ by returning pointers to static strings.  The other two function
tests require thread-local storage to be thread-safe.

One idea I have is to add the thread test compile/link/run test into
configure, to be run when you ask for threads.  That way, we eliminate
per-platform test reports (with the possibility that different OS
versions have different thread safety characteristics), and we can throw
an error if we don't find the function threadsafe or don't find the *_r
version.

Another idea is to change the test program to set three variables, one
for each function tested, and throw an #error in the code if the
function isn't thread-safe and if there is no *_r.  I think in those
cases we can remove the thread.c code that handles non-thread-safe libc
with no *_r function.

Basically, I was too coarse-grained with NEED_REENTRANT_FUNCS to throw
an error if there isn't a thread-safe function because we might have
platforms that have a thread-safe strerror, but not strerror_r, and *_r
versions of the other functions.  In that case, we would have
NEED_REENTRANT_FUNCS=yes, and without strerror_r, we would fail, even
though strerror itself might be thread-safe.

I will start working on spliting NEED_REENTRANT_FUNCS up into three
variables and we can add a configure test later if folks think that is a
good idea.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073