Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) - Mailing list pgsql-hackers

Philip Yarra wrote:
> On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
> 
> Okay, here's results from the machines I have access to... I think what you're 
> going to find is that an awful lot of platforms that do support pthreads do 
> not necessarily provide thread-safe libc functions. 

I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
below.

> Is it possible to identify which functions are likely to be called by multiple 
> threads and create our own mutex-wrapper functions for them? Disabling 
> thread-safety seems pretty drastic simply because of a lack of getpwuid_r() 
> or thread-safe getpwuid(). Or do I misunderstand your concerns?

I am starting to think your approach is the only way to go --- I was
thinking of it for FreeBSD, but now, with these additional platforms, it
seems almost a requirement.

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?

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.

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?


---------------------------------------------------------------------------

> 
> Regards, Philip.
> 
> $ 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
> 
> There are older _r functions, but they're deprecated as the non _r are now 
> thread-safe.
> 
> $ uname -a
> SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
> $ gcc -lpthread -lnsl test.c # this works
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> getpwduid_r provided
> gethostbyname_r not provided
> 
> FreeBSD 5.1 (i386)
> $ cc -pthread test.c
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> manpage notes "BUGS
>      These functions use static data storage; if the data is needed for future
>      use, it should be copied before any subsequent calls overwrite it."
> 
> FreeBSD 4.8 (i386)
> $ cc -pthread test.c
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> manpage notes "BUGS
>      These functions use static data storage; if the data is needed for future
>      use, it should be copied before any subsequent calls overwrite it."
> 
> Linux 2.4.18-3 (i686)
> $ ./a.out
> Your gethostbyname() is _not_ thread-safe
> Your getpwuid() is _not_ thread-safe
> Your functions are _not_ all thread-safe
> 
> manpage notes "The  functions  gethostbyname()  and gethostbyaddr() may return 
> pointers to static data, which may be over-
>        written by later calls. Copying the struct hostent does not suffice, 
> since it contains pointers  -  a  deep
>        copy is required.
> 
> Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().  
> These return 0 on success and
>        nonzero  on  error.  The  result of the call is now stored in the 
> struct with address ret.  After the call,
>        *result will be NULL on error or point to the result on success.  
> Auxiliary data is stored  in  the  buffer
>        buf  of  length buflen.  (If the buffer is too small, these functions 
> will return ERANGE.)  No global vari-
>        able h_errno is modified, but the address of a variable in which  to  
> store  error  numbers  is  passed  in
>        h_errnop."
> 

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