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