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

[ I have retained the original email below so people can remember where
we left this.]

After much agonizing, I have applied a patch to attempt threading in
this order:

use non-*_r function names if they are all thread-safe
(NEED_REENTRANT_FUNCS=no)
use *_r functions if they exist (configure test)
do our own locking and copying of non-threadsafe functions

With Solaris, FreeBSD, and OSF failing our existing setup, the last
option of doing our own locking and copying seemed necessary. The good
news is that this is used only if another method can not be found. I
used the 'bind' source code as an example of how to do this.

Patch sent to patches list.

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

Bruce Momjian wrote:
> 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(at)candle(dot)pha(dot)pa(dot)us | (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 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

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