Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)

Philip Yarra wrote:
> On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> > I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
> > below.
> 
> Actually, I am not sure the OSF failure is correctly reported... your test app 
> had me a little baffled in that case.

Baffler is my middle name.  ;-)

Anyway, the output was:
$ uname -aOSF1 hostname V4.0 1229 alpha$ ./a.outYour getpwuid() changes the static memory area between callsYour
strerror()is _not_ thread-safeYour functions are _not_ all thread-safe
 

What that says is that getpwuid doesn't return the same pointer value
for two calls even in the same thread.  C comments say:
*  This program first tests to see if each function returns a constant*  memory pointer within the same thread, then,
assumingit does, tests*  to see if the pointers are different for different threads.  If they*  are, the function is
thread-safe.

So my guess is that OSF returns a pointer into a pre-allocated area that
it allocates for every user in the database, or at least on every call
to a username --- perhaps it creates a hash in libc indexed by username
--- anyway, it is probably threadsafe, but strerror isn't, so we are
dead anyway.  :-)

> > We would have to get some thread mutex, make the function call, copy the
> > return values into the passed pointer, and release the mutex?  Do we
> > test to see if we are in thread mode before doing the locking?  Is that
> > test even possible or desirable?
> 
> I guess as with the threading stuff in ECPG:
> 
> #ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
> pthread_mutex_lock(&my_mutex)
> #endif
> 
> /* do stuff */
> 
> #ifdef SOME_DEF 
> pthread_mutex_unlock(&my_mutex)
> #endif

Yep.  Ugly but required.

> > Seems we will need to rename the config variable to be
> > NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
> > *_r function, and fall back to the mutex if both settings are false.
> 
> Yeah, or you could just always use the wrapper and not try to do all the test 
> in configure... doubtless less efficient, but maybe better for the mental 
> health...

True.  In fact, on platforms with non-*_r functions that are
thread-safe, those locks are already done in libc anyway.  The problem
is that on platforms that don't have non *_r thread-safe, and don't
have all the *_r functions, we would be adding overhead to libpq that
isn't already part of libc on that platform, and that seems wrong to me.
We might have to produce a libpq_r and ecpg_r (yuck) on those platforms.

Double-yuck.

> > This part has me concerned too:
> > > Copying the struct hostent does not suffice, since it contains
> > > pointers  -  a  deep copy is required.
> >
> > Would someone with thread mutex experience assist me?
> 
> Ummm... replace /* do stuff /* above with a deep copy of the hostent struct. 
> I'll give that a shot if you like.

Tripple-yuck.  :-)

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