--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
> Larry Rosenman wrote:
>> >> >> Bruce Momjian writes:
>> >> >> > Right. We can't assume because a *_r function is missing that
>> >> >> > the normal function is thread-safe.
>> >> >
>> >> >> That's not our concern - if the OS isn't thread safe we can't do
>> >> >> anything about it, and to worry about it is an enormous waste of
>> >> >> development time.
>> >> >
>> >> > There is a long way between configure not finding a particular *_r
>> >> > function and the entire operating system not being thread-safe.
>> >> > There are many uncertainties along that way, and I believe my point
>> >> > was that the only way we can get a degree of certainty about the
>> >> > result of a particular build is that we keep a database of exactly
>> >> > what is required for thread-safety on each platform.
>> >> Ok, now, is my statement from a SCO Developer good enough to get
>> >> thread-safety enabled
>> >> on UnixWare with only the getpwuid_r() function?
>> >
>> > Woh, I thought we just agreed that getpwuid_r() isn't required for
>> > thread-safety on your platform.
>> it's CLEANER to use it.
>>
>> Our API Signature is the _r version, why not use it when it's available?
>
> My new patch will optionally use it if it exists, but we still need to
> know if it is required so if we don't find it, we throw an error.
On UnixWare, either should be thread-safe, to the best of my knowledge.
HOWEVER,
UnixWare has the getpwuid_r version, and since our API(from thread.c) is
the _r signature,
we should just return getpwuid_r(...,....,..., etc).
LER
--
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