Tom Lane writes:
> I have heard that the reentrant libc is significantly worse-performing
> than the non-reentrant one on some platforms. This is not real hard
> to believe, since functions as common as malloc() will need locking
> overhead if they think they might be in a multithreaded environment.
Then maybe we should make a libpq and a libpq_r, etc. Then users have the
choice when they build their applications, and don't already have to think
about what their applications may require when building PostgreSQL.
(There is a libmysqlclient and a libmysqlclient_r, FWIW.)
> > _POSIX_PTHREAD_SEMANTICS isn't used anywhere in the entire system, the
> > effect of _THREAD_SAFE is to define _REENTRANT, and the effect of
> > _REENTRANT is to declare getlogin_r(), which PostgreSQL sources don't use.
>
> On which version of Linux are the above statements true? Are you sure
> they are true on other versions?
The documentation tells:
- Macro: _REENTRANT
- Macro: _THREAD_SAFE
If you define one of these macros, reentrant versions of several
functions get declared.
However, no function is specifically documented to require these macros.
Also, according to the change log of glibc, this state has existed since
about 1996, just the set of xxx_r() functions that were covered by these
macros has changed now and then.
SUSv3 documents a number of xxx_r() functions, but it doesn't speak of
_REENTRANT or _THREAD_SAFE anywhere.
So what I'm looking for is some documentation that states that such and
such flags is required to get such and such effect.
--
Peter Eisentraut peter_e@gmx.net