Re: thread safety tests

Jan Wieck wrote:
> On 6/9/2004 9:36 AM, Bruce Momjian wrote:
> > 
> >> Also, I would suggest that we allow to build the libpq with thread 
> >> specific compiler options, even if it is not entirely thread safe. It 
> >> would require that a really multithreaded application has to have 
> >> mutexes around certain operations, but being entirely unable to 
> >> configure in a way that adds thread compile options to the CFLAGS makes 
> >> libpq completely useless for multithreaded programs on some platforms 
> >> (for example Solaris).
> > 
> > I am confused what you are suggesting.  Are you saying to use thread
> > flags but not the other things that make is thread-safe?  There isn't
> > much else other than the flags actually.  Now that more OS's are
> > thread-safe by default, we could consider using threading if it is
> > available by default.  We would need some way of reporting that to the
> > user, perhaps via an installed readme file or a pg_config output option.
> 
> The problem is that if your thread-safety tests fail, there is no way to 
> build libpq with -pthread and -DREENTRANT or whatever is required on 
> that platform. On Solaris this results in errno being defined as
> 
>      extern int errno;
> 
> as supposed to
> 
>      #define errno *(errno())
> 
> which makes libpq on Solaris completely useless for every program that 
> uses threads for "something". There is still value in compiling it with 
> thread support compiler flags, even if it will not result in a thread 
> safe libpq.

Well, first we should find out how to get the thread test to pass for
that patform, but for cases where we can't (FreeBSD doesn't have
getpwuid_r(), we are stuck.  (That might be your Solaris problem as
well.)

I looked over the code and the only place getpwuid_r (through
pqGetpwuid) is used is in libpq to look up the default username based on
the euid for the connection to the backend.  Unfortunately, I can't find
any other way to do such a lookup in a thread-safe manner unless we do a
system() or lock/read /etc/passwd ourselves, both of which are ugly.

I can't imagine how some OS's cannot give us a thread-safe way to do
this.  

When FreeBSD can't enable threads in 7.5, folks are going to be upset. 
In 7.4 we allowed it by having our own C code lock/copy the passwd
structure, but someone pointed out that calls to getpwuid() in other
places in the client code don't have such locking, so it would not work,
so it was removed for 7.5.

--  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