Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Date | |
Msg-id | 200309011635.h81GZhJ14688@candle.pha.pa.us Whole thread Raw |
In response to | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) (Greg Stark <gsstark@mit.edu>) |
Responses |
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
List | pgsql-hackers |
Greg Stark wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > > Lee Kindness writes: > > > > > You don't... and you simply shouldn't care. If there is a_r version > > > available then we should use it - even if the plain version is "safe". > > > > The problem with this is that the automatic determination (in configure) > > whether there is a xxx_r() version is, in general, fragile. We cannot > > rely on configure saying that xxx_r() doesn't exist, so the plain xxx() > > should be good enough. Else, we'd be shipping claimed-to-be-thread-safe > > libraries that might trigger bugs that will be hard to track down. > > Um. I don't think that's true. I mean, in theory it's true, but in practice > why would an OS have some *_r but have only non-thread-safe versions of > others? Oh, interesting. So you are saying that if the OS supports threads, then we use the *_r if they have them, and assume the non *_r functions are already thread-safe if they don't. Interesting. That seems to be what we have on Unixware, and on BSD/OS I have some *_r functions but not others, but they are all threadsafe, so your plan works there too. > The only OSes like that would be ones that were in the process of developing > thread-safe libraries and hadn't finished yet. Perhaps early versions of > Solaris or CVS snapshots of BSD? I don't know of any actual releases that > anyone would want to be running today. > > Postgres doesn't need to work around problems like that. At worst it should > have a blacklist of OS versions that it knows not to even bother building a > threadsafe libpq for. We could go down that road. The only other OS that needs *_r functions is Linux, and it uses all *_r functions. How do we configure to throw an error in that OS if we don't fined all of them? Maybe we need a three-valued variable instead of boolean NEED_REENTRANT_FUNC_NAMES. We could call it just REENTRANT_FUNC_NAMES and it could have values 'require', 'prefer', 'disable'. This mimicks libpq's new PGSSLMODE values. That sounds like a clear plan. -- 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: