Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
От | Bruce Momjian |
---|---|
Тема | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Дата | |
Msg-id | 200309011705.h81H5kM18004@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Greg Stark wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > 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. > > Actually I don't think that's true for linux. Linux only has *_r functions > that are required, not unnecessary ones. > > Note that there are two different types of _r functions being discussed here. > > getpwuid, for example, has a thread-safe API. There's really no reason for a > getpwuid_r to exist on any platform. If it exists then it must simply be a > thread-safe version of the regular function. But if it doesn't the regular > function must be thread-safe if the platform supports threads at all. > > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe > APIs. They can never be made thread-safe. The *_r versions of these functions > are standardized and required. If they don't exist then the platform simply > does not support threads. > > My questions are: > > Are there OSes that have strtok_r et al. because standards require them but > have no OS threads support at all? In which case the library would be > "thread-safe" but not really usefully so. > > Are there OSes that have extraneous *_r functions like getpwuid_r but only for > compatibility and they're deprecated? Have you read the comment at the top of port/thread.c? There is a way to make those thread-safe using per-thread global variables, I think. Anyway, require doesn't mean we need all the *_r functions that exist, just that we need the *_r functions that appear in thread.c. -- 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 по дате отправления: