Re: [PATCHES] UPDATED UnixWare Threads Patch. - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCHES] UPDATED UnixWare Threads Patch.
Date
Msg-id 200308142115.h7ELF9x08760@candle.pha.pa.us
Whole thread Raw
List pgsql-hackers
I posted this to patches, but the hackers list should be aware of the
current thread library issues.

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

Bruce Momjian wrote:
> 
> OK, I have applied the attached patch.
> 
> Here is the comment I have added to the thread.c file:
> 
> /*
>  *    Threading sometimes requires specially-named versions of functions
>  *    that return data in static buffers, like strerror_r() instead of
>  *    strerror().  Other operating systems use pthread_setspecific()
>  *    and pthread_getspecific() internally to allow standard library
>  *    functions to return static data to threaded applications.
>  *
>  *    Additional confusion exists because many operating systems that
>  *    use pthread_setspecific/pthread_getspecific() also have *_r versions
>  *    of standard library functions for compatibility with operating systems
>  *    that require them.  However, internally, these *_r functions merely
>  *    call the thread-safe standard library functions.
>  *
>  *    For example, BSD/OS 4.3 uses Bind 8.2.3 for getpwuid().  Internally,
>  *    getpwuid() calls pthread_setspecific/pthread_getspecific() to return
>  *    static data to the caller in a thread-safe manner.  However, BSD/OS
>  *    also has getpwuid_r(), which merely calls getpwuid() and shifts
>  *    around the arguments to match the getpwuid_r() function declaration.
>  *    Therefore, while BSD/OS has getpwuid_r(), it isn't required.  It also
>  *    doesn't have strerror_r(), so we can't fall back to only using *_r
>  *    functions for threaded programs.
>  *
>  *    The current setup is to assume either all standard functions are
>  *    thread-safe (NEED_REENTRANT_FUNC_NAMES=no), or the operating system
>  *    requires reentrant function names (NEED_REENTRANT_FUNC_NAMES=yes).
>  */
> 
> As an additional data point, here is a README comment from Bind 8.2.3:
> 
>   Thread Safety:
> 
>           It is possible for a thread safe program to be altered to call the
>   underlying interface (rather than the standard getXbyY() stubs) and get some
>   reentrance capabilities.  Note that the underlying libraries (which we call)
>   are not all thread-safe, for example, the YP and DNS resolvers.  A lot more
>   work will need to be done before we have full thread safety.  But we believe
>   that the native API for this system does not impose any reentrancy problems.
>   We don't use global or static variables anywhere except in the getXbyY() stubs.
> 
> Here is Bind's gethostbyname_r:
>  
>     HOST_R_RETURN
>     gethostbyname_r(const char *name,  struct hostent *hptr, HOST_R_ARGS) {
>         struct hostent *he = gethostbyname(name);
>     
>         HOST_R_ERRNO;
>     
>         if (he == NULL)
>             return (HOST_R_BAD);
>     
>         return (copy_hostent(he, hptr, HOST_R_COPY));
>     }
> 
> As you can see, it merely calls gethostbyname() and adjusts to return
> the proper values.
> 
> I removed the pre-POSIX getpwuid_r function call and added the POSIX
> one.  If we need the pre-POSIX one, we can add it with a configure
> test, but I would rather find out if someone needs it first.  The
> original thread patch that was posted had only the pre-POSIX version of
> the function, and I am not sure why the didn't include the POSIX one
> too, or use that instead of the pre-POSIX one.
> 
> There are also a few stylistic function declaration cleanups.
> 
> The unixware optimizer changes have already been applied.

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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: New function: epoch_to_timestamp...
Next
From: Bruce Momjian
Date:
Subject: Re: getting confused parsing ACLITEMS...