--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
