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 -a
OSF1 hostname V4.0 1229 alpha
$ ./a.out
Your getpwuid() changes the static memory area between calls
Your strerror() is _not_ thread-safe
Your 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, assuming it 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
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
