Re: libpq_r - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: libpq_r
Date
Msg-id 200307241444.h6OEiRK23239@candle.pha.pa.us
Whole thread Raw
In response to Re: libpq_r  (Lee Kindness <lkindness@csl.co.uk>)
Responses Re: libpq_r  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: libpq_r  (Lee Kindness <lkindness@csl.co.uk>)
Re: libpq_r  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Lee Kindness wrote:
> Tom Lane writes:
>  > Lee Kindness <lkindness@csl.co.uk> writes:
>  > > Bruce Momjian writes:
>  > >>> My guess is that if the OS has separate threaded libs, we have to mimic
>  > >>> that stuff.
>  > > But there are NO thread primitives/calls in libpq 
>  > That's not the point.  The point is stuff that isn't necessarily visible
>  > in the source code --- such as what method it uses to get at "errno",
>  > whether it's linked to thread-safe versions of malloc and other libc
>  > routines, etc.
>  > If the OS supplies both libc and libc_r, it is unlikely to be a good
>  > idea to link a threaded libpq with libc, or a non-threaded libpq with
>  > libc_r.
> 
> No, that is the point exactly... I know fine well the visibility of
> errno and the different ways it may be implemented. You'll find it
> hard to come across an OS which doesn't "do the right thing" WRT to
> using reentrant functions and "wrappers" if _REENTRANT is defined
> during the compile...
> 
> That is ALL that is needed, lets not complicate the issue...
> 
> And what do you mean by "threaded libpq" and "non-threaded libpq" - as
> I say above there are NO thread primitives being used in libpq. It's
> just clean reentrant code... This change/patch should be done
> irregardless of the move to thread safety!

Now I see what you are saying, that _REENTRANT just makes it reentrant,
and doesn't have a downside in terms of performance.

However, notice the flags needed under Linux:
THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"

or are you saying libpq needs only the first one because libpq, itself,
doesn't use threads --- interesting distinction, and perhaps a way we
can get by with one libpq even on platforms that require *_r libraries.

As you mentioned, ecpg is another manner, but I think perhaps an ecpg
flag could allow both threaded and nonthreaded.

--  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:

Previous
From: Lee Kindness
Date:
Subject: Re: libpq_r
Next
From: Lee Kindness
Date:
Subject: Re: libpq_r