Re: libpq_r - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: libpq_r
Date
Msg-id Pine.LNX.4.56.0307251114190.1545@krusty.credativ.de
Whole thread Raw
In response to Re: libpq_r  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: libpq_r  (Larry Rosenman <ler@lerctr.org>)
Re: libpq_r  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: libpq_r  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Bruce Momjian writes:

> I still think it is confusing to create a libpq_r on platforms that have
> no _r libraries.  I am on BSD/OS and I can find only _r library on my
> entire system,

The criterion is not whether the platform has _r libraries, it's whether
special actions are required in order to make a library fit for threaded
programs, at the time that library is built.  Such special actions may
include:

1. need to link in special libc_r (FreeBSD)
2. need to use magic flags for compiler and/or linker (FreeBSD, UnixWare)
3. need to compile with special preprocessor symbols (UnixWare, AIX)
4. need to use different compiler altogether (AIX)

(If you read between the lines of the manufacturers' documentation, all
these methods end up accomplishing similar things, they are only different
interfaces for it.)

If any of these cases apply, we need to provide a separate libpq_r, or
else either threaded land or nonthreaded land will suffer pain, from what
I read.  (The simplest example is errno being defined in different ways
and referring to different symbols.)

If none of these cases apply, then a separate libpq_r will be redundant,
perhaps "confusing" to some, but it can be ignored by the user.

-- 
Peter Eisentraut   peter_e@gmx.net


pgsql-hackers by date:

Previous
From: Thomas Swan
Date:
Subject: Re: SELECT FOR UPDATE
Next
From: Larry Rosenman
Date:
Subject: Re: libpq_r