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

Larry Rosenman <ler@lerctr.org>

From: Larry Rosenman <ler@lerctr.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, Lee Kindness <lkindness@csl.co.uk>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Kurt Roeckx <Q@ping.be>, Peter Eisentraut <peter_e@gmx.net>, "Marc G. Fournier" <scrappy@hub.org>, "Marc G. Fournier" <scrappy@postgresql.org>, Greg Stark <gsstark@mit.edu>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2003-09-01T20:05:57Z
Lists: pgsql-hackers

--On Monday, September 01, 2003 16:01:16 -0400 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Lee Kindness <lkindness@csl.co.uk> writes:
>> Guys, too much thought is being spent on this...
>> 1. For the _r functions we "need" we should ALWAYS use them if the
>> system we are building on has them - they WILL be thread-safe.
>
>> 2. If the system is missing a _r function then we implement a wrapper
>> to call the normal non-_r version. However we do NOT make this wrapper
>> call thread-safe - we assume the non-_r version already is.
>
> That assumption is exactly what Peter is unhappy about.  With the above
> approach we will happily build a "thread safe" library on systems that
> are in fact not thread safe at all.  Peter wants --enable-thread-safety
> to fail on non-safe systems.
then how do we *PROVE* thread-safety on a particular platform?

In my case on UnixWare, we assume all libc is thread-safe except for those 
that
are specifically called out.

the getpwuid() function has a _r version, so we can use that.  the 
gethostbyname and strerror functions do *NOT* have a _r version, but are 
assumed thread-safe.

The current (cvs) version can't build a thread-safe libpq, but with my 
patch it does build.

LER

>
> 			regards, tom lane



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749