Re: Thread-safe configuration option appears to - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Thread-safe configuration option appears to
Date
Msg-id Pine.LNX.4.56.0308052111190.928@krusty.credativ.de
Whole thread Raw
In response to Re: Thread-safe configuration option appears to  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Thread-safe configuration option appears to
List pgsql-hackers
Bruce Momjian writes:

> First get your own platforms enabled for the existing thread flag, and
> we can revisit this when most/all our platforms are supported.  We want
> to avoid confusion of having things work for some platforms and not
> others with no way to communicate that to the users.

Yes, let's settle on that for now (= release 7.4): Without
--enable-thread-safety, you get the same old; with --enable-thread-safety,
you get _REENTRANT (or equivalent) for libpq and libecpg, and you get
pthreads in libecpg.  Then users and packagers can judge the impact on
their platform for themselves.  While the release is out there, we can
gather more data on this and information for the forgotten platforms, and
then for 7.5 we might have something that pleases more people by default.

Where I see this going, however, is three buckets: one group of platforms
will have near zero impact and there will be pressure to enable thread
safety by default (BSD/OS, Linux, UnixWare), a second group of platforms
where there will be an endless debate about which is right (FreeBSD, AIX),
and a third group of platforms that have no thread-safety no matter how
hard you look (mostly the old ones).  So in the end we will either have to
document "libpq is thread-safe on platform A, B, and C", or we will have
to keep the switch for all platforms and leave it off by default.

-- 
Peter Eisentraut   peter_e@gmx.net


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: cvs branch to use?
Next
From: Peter Eisentraut
Date:
Subject: Re: 7.4 beta binaries