Re: Thread configure flag

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > If it is the default, libpq is going to use the libc_r library, at least
> > on some platforms, and that may not be desired.
>
> But what is the objective reason for this lack of desire?

libc_r could behave differently than libc on some platforms --- this is
the reason we don't use some semaphore stuff in pthreads in backend code
--- we don't know the ramifications.

Also, --with-threads adds threading calls to ecpg, which I am not sure
everyone would want in the default case.

> > One funny thing is that on BSD/OS and NetBSD, because there are no
> > thread compile flags, function names, or libraries, libpq is the same
> > code with or without the flag.  ecpg, however, has thread calls, and is
> > effected on every platform.
>
> Well, I'm pretty sure that the current thread options are overkill and can
> be simplified.  For instance, on Linux the template currently claims

No question.  I just grabbed all the flags suggested.  Many OS's are
going to require such tweeking.

> THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
>
> _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.
> In other words, this can be removed.

You mean none of them are needed?  Why would _REENTRANT only control
getlogin_r()?  Are all the other functions thread-safe already?

--
  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, Pennsylvania 19073