PostgreSQL libraries - PThread Support, but not use...
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads. I'm largely there with ecpg (globals
are protected, a sqlca for each thread), but of course it relies on
libpq which needs work to share a connection between thrreads.
Relying on thread experience from a few years back on Solaris I had
assumed I could just use the pthread_* routines in the shared
libraries and they would reference the weak symbols in libc, rather
than explicitly pull in libpthread. If the application using the
library linked to libpthreads then the 'real' thread routines would be
activated, single threaded apps wouldn't need link to
libpthread... However there seems to be no standard to which pthread_*
routines are available as weak symbols in libc (Linux and Solaris
differ).
So a couple of questions to decide the course of this work:
1. It's looking likely that the libraries will need to link to
libpthread, and as a result anything linking to the libraries will
need to link to libpthread too. Will this be accepted in a patch? A
similar problem has cropt up with the perl integration recently too
(i.e. the Perl developers have decided to link in libpthread).
2. Is their any mileage in using an abstraction layer - ACE, npr? A
Bit OTT for what i'm doing, but...
3. Am I wasting my time?
I think making the PostgreSQL libraries thread-safe/aware is very
worthwhile, but a lot of hurdles...
Thanks, Lee.
Lee Kindness <lkindness@csl.co.uk> writes:
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads. I'm largely there with ecpg (globals
are protected, a sqlca for each thread), but of course it relies on
libpq which needs work to share a connection between thrreads.
AFAIK, libpq is thread-safe already, it's just not thread-aware.
What you'd presumably want is a wrapper layer that adds a mutex to
prevent multiple threads from manipulating a PGconn at the same time.
Couldn't this be done without touching libpq at all?
1. It's looking likely that the libraries will need to link to
libpthread, and as a result anything linking to the libraries will
need to link to libpthread too. Will this be accepted in a patch?
If the patch requires pthread and not any other form of thread support,
probably not. See nearby threading thread ;-)
In general I'd be unhappy with doing anything to libpq that forces
non-threaded clients to start depending on libpthread (or other thread
libraries). Thus the idea of a wrapper seems more appealing to me.
regards, tom lane
On Mon, Jan 06, 2003 at 11:58:17AM -0500, Tom Lane wrote:
AFAIK, libpq is thread-safe already, it's just not thread-aware.
What you'd presumably want is a wrapper layer that adds a mutex to
prevent multiple threads from manipulating a PGconn at the same time.
Couldn't this be done without touching libpq at all?
In fact it'd probably be better to do it without touching libpq at all,
so the application can tune for the level of thread-safety it needs.
There's no point in locking a PGresult for every time the application
wants to read a field--it'd be unacceptably slow yet some applications
may want to do it. But I'm sure this has been discussed in that other
threading thread...
Having a thread-aware wrapper multiplex a PGconn between multiple
client threads using the nonblocking functions probably isn't going to
wash either, because nonblocking operation isn't quite the same as fully
asynchronous. And even if the backend protocol allows for it, there's
no great benefit since the threads would still be waiting on the same
socket and the same backend. Better to give each thread its own PGconn
and its own file descriptor to block on, if needed.
Jeroen
Tom Lane writes:
Lee Kindness <lkindness@csl.co.uk> writes:
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads. I'm largely there with ecpg (globals
are protected, a sqlca for each thread), but of course it relies on
libpq which needs work to share a connection between thrreads.AFAIK, libpq is thread-safe already, it's just not thread-aware.
What you'd presumably want is a wrapper layer that adds a mutex to
prevent multiple threads from manipulating a PGconn at the same time.
Couldn't this be done without touching libpq at all?
Certainly, it could. I've not fully investigated the current failings
of libpq WRT to threading yet. But it's certainly a bit more than I
stated above. I don't know where the statement that libpq is thread
safe originated from (I see it's on the website). but at a quick
glance I believe that krb4, krb5, PQoidStatus(),
PQsetClientEncoding(), winsock_strerror() need more though
investigation and non-thread-safe fuctions are also being used (at a
glance gethostbyname() and strtok()).
1. It's looking likely that the libraries will need to link to
libpthread, and as a result anything linking to the libraries will
need to link to libpthread too. Will this be accepted in a patch?If the patch requires pthread and not any other form of thread support,
probably not. See nearby threading thread ;-)
In general I'd be unhappy with doing anything to libpq that forces
non-threaded clients to start depending on libpthread (or other thread
libraries). Thus the idea of a wrapper seems more appealing to me.
Okay, but what about ecpg? Thread-local sqlca instances would be a
real benefit, guess Michael and Christof are the guys to talk to?
I suppose the real problem is the needed baggage with this - the
autoconf macros will be a nightmare!
Thanks, Lee.
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should. We have been making
marginal thread-safe improvements over the years.
---------------------------------------------------------------------------
Lee Kindness wrote:
Tom Lane writes:
Lee Kindness <lkindness@csl.co.uk> writes:
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads. I'm largely there with ecpg (globals
are protected, a sqlca for each thread), but of course it relies on
libpq which needs work to share a connection between thrreads.AFAIK, libpq is thread-safe already, it's just not thread-aware.
What you'd presumably want is a wrapper layer that adds a mutex to
prevent multiple threads from manipulating a PGconn at the same time.
Couldn't this be done without touching libpq at all?Certainly, it could. I've not fully investigated the current failings
of libpq WRT to threading yet. But it's certainly a bit more than I
stated above. I don't know where the statement that libpq is thread
safe originated from (I see it's on the website). but at a quick
glance I believe that krb4, krb5, PQoidStatus(),
PQsetClientEncoding(), winsock_strerror() need more though
investigation and non-thread-safe fuctions are also being used (at a
glance gethostbyname() and strtok()).1. It's looking likely that the libraries will need to link to
libpthread, and as a result anything linking to the libraries will
need to link to libpthread too. Will this be accepted in a patch?If the patch requires pthread and not any other form of thread support,
probably not. See nearby threading thread ;-)
In general I'd be unhappy with doing anything to libpq that forces
non-threaded clients to start depending on libpthread (or other thread
libraries). Thus the idea of a wrapper seems more appealing to me.Okay, but what about ecpg? Thread-local sqlca instances would be a
real benefit, guess Michael and Christof are the guys to talk to?I suppose the real problem is the needed baggage with this - the
autoconf macros will be a nightmare!Thanks, Lee.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
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 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should.
We do:
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
But Lee's point about depending on possibly-unsafe libc routines is a
good one. I don't think anyone's gone through the code with an eye to
that.
regards, tom lane
On Monday 06 January 2003 12:28, Lee Kindness wrote:
Tom Lane writes:
Lee Kindness <lkindness@csl.co.uk> writes:
are protected, a sqlca for each thread), but of course it relies on
libpq which needs work to share a connection between thrreads.
AFAIK, libpq is thread-safe already, it's just not thread-aware.
Couldn't this be done without touching libpq at all?
Certainly, it could. I've not fully investigated the current failings
of libpq WRT to threading yet. But it's certainly a bit more than I
stated above. I don't know where the statement that libpq is thread
safe originated from (I see it's on the website). but at a quick
glance I believe that krb4, krb5, PQoidStatus(),
PQsetClientEncoding(), winsock_strerror() need more though
investigation and non-thread-safe fuctions are also being used (at a
glance gethostbyname() and strtok()).
Lee, see the AOLserver source code. AOLserver (www.aolserver.com) is a
multithreaded dynamic web server that supports pooled database connections.
One of the supported databases is PostgreSQL (I maintain the driver,
currently). It's dual licensed (AOLserver Public License and GPL). I've not
yet seen a problem that could be traced to libpq not being threadsafe. And
AOLserver certainly would show a non-threadsafe problem, particularly with
sites running OpenACS, which can easily beat the database to death.
BTW: thanks for the Bison RPMs. And I believe the PGDG is appropriate as
well. :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Tom Lane writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should.We do:
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
But Lee's point about depending on possibly-unsafe libc routines is a
good one. I don't think anyone's gone through the code with an eye to
that.
Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of "known bad"
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place of the traditional ones where
available.
If any function is found to be not thread-safe and cannot be made so
using standard library calls then it needs to be documented as such
both in the source and the aforementioned documentation.
This approach avoids any thread library dependencies and documents the
current state of play WRT thread safety (i.e it's a good, and needed,
basis for any later work).
ECPG is a separate issue, and best handled as such (it will need
thread calls). I'll post a patch for it at a later date so the changes
are available to anyone who wants to play with ECPG and threads.
Ta, Lee.
Lee Kindness wrote:
Tom Lane writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should.We do:
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
But Lee's point about depending on possibly-unsafe libc routines is a
good one. I don't think anyone's gone through the code with an eye to
that.Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of "known bad"
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place of the traditional ones where
available.
I am a little confused by the *_r functions. Are they for all
functions? BSD/OS doesn't have them, but all our libc functions are
threadsafe except for things like strtok, where they recommend strsep,
and gethostbyname, where they would suggest getaddrinfo, I guess.
If any function is found to be not thread-safe and cannot be made so
using standard library calls then it needs to be documented as such
both in the source and the aforementioned documentation.
Ideally we will find we can get them all fixed in some way.
This approach avoids any thread library dependencies and documents the
current state of play WRT thread safety (i.e it's a good, and needed,
basis for any later work).
Yes, good idea.
ECPG is a separate issue, and best handled as such (it will need
thread calls). I'll post a patch for it at a later date so the changes
are available to anyone who wants to play with ECPG and threads.
Yes, needs to be done too. Someone was complaining about ecpg not being
thread safe several months ago. I don't remember the details.
--
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 19073Bruce Momjian writes:
Lee Kindness wrote:
Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of "known bad"
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place of the traditional ones where
available.I am a little confused by the *_r functions. Are they for all
functions? BSD/OS doesn't have them, but all our libc functions are
threadsafe except for things like strtok, where they recommend strsep,
and gethostbyname, where they would suggest getaddrinfo, I guess.
Some functions in the C library (and other common system libraries)
are defined in such a way to make their implementation
non-reentrant. Normally this is due to return values being supplied in
a static buffer which is overwritten by the subsequent call, or the
calls relying on static data between calls. A list such functions
would include:
asctime crypt ctime drand48 ecvt encrypt erand48 fcvt fgetgrent
fgetpwent fgetspent getaliasbyname getaliasent getdate getgrent
getgrgid getgrnam gethostbyaddr gethostbyname gethostbyname2
gethostent getlogin getnetbyaddr getnetbyname getnetent getnetgrent
getprotobyname getprotobynumber getprotoent getpwent getpwnam getpwuid
getservbyname getservbyport getservent getspent getspnam getutent
getutid getutline gmtime hcreate hdestroy hsearch initstate jrand48
lcong48 localtime lrand48 mrand48 nrand48 ptsname qecvt qfcvt rand
random readdir readdir64 seed48 setkey setstate sgetspent srand48
srandom strerror strtok tmpnam ttyname
to one degree or another. The important ones to watch for are: ctime,
localtime, asctime, gmtime, readdir, strtok and tmpnam. Now these
functions are often augmented by a _r partner which fixes their API to
allow their implementations to be reentrant.
After a quick grep libpq could be using crypt, gethostbyname, random,
strerror, encrypt, getpwuid, rand and strtok. As you rightly note, ins
ome cases the correct fix is to use alternative functions and not the
_r versions - this avoids lots of ifdefs!
L.
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.
Thanks, Lee.
Lee Kindness writes:
Show quoted text
Tom Lane writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should.We do:
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
But Lee's point about depending on possibly-unsafe libc routines is a
good one. I don't think anyone's gone through the code with an eye to
that.Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of "known bad"
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place of the traditional ones where
available.If any function is found to be not thread-safe and cannot be made so
using standard library calls then it needs to be documented as such
both in the source and the aforementioned documentation.This approach avoids any thread library dependencies and documents the
current state of play WRT thread safety (i.e it's a good, and needed,
basis for any later work).ECPG is a separate issue, and best handled as such (it will need
thread calls). I'll post a patch for it at a later date so the changes
are available to anyone who wants to play with ECPG and threads.Ta, Lee.
Guys, just posted patches for libpq to address thread-safe issues. Now
uses strerror_r(), gethostbyname_r(), getpwuid_r() and crypt_r() where
available. Passes all tests on Linux and Solaris.
Any comments let me know - my first major(ish) outing in the
PostgreSQL source, in particular I'm not use in the configure stuff is
100% right...
Patches also at:
http://services.csl.co.uk/postgresql/diffs-20030109-configure.txt.gz
http://services.csl.co.uk/postgresql/diffs-20030109-libpq.txt.gz
Thanks, Lee.
Lee Kindness writes:
Show quoted text
Tom Lane writes:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should.We do:
http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html
But Lee's point about depending on possibly-unsafe libc routines is a
good one. I don't think anyone's gone through the code with an eye to
that.Right, so a reasonable angle for me to take is to go through the libpq
source looking for potential problem areas and use of "known bad"
functions. I can add autoconf checks for the replacement *_r()
functions, and use these in place of the traditional ones where
available.If any function is found to be not thread-safe and cannot be made so
using standard library calls then it needs to be documented as such
both in the source and the aforementioned documentation.This approach avoids any thread library dependencies and documents the
current state of play WRT thread safety (i.e it's a good, and needed,
basis for any later work).ECPG is a separate issue, and best handled as such (it will need
thread calls). I'll post a patch for it at a later date so the changes
are available to anyone who wants to play with ECPG and threads.Ta, Lee.
Lee Kindness <lkindness@csl.co.uk> writes:
+ #define _THREAD_SAFE + #define _REENTRANT + #define _POSIX_PTHREAD_SEMANTICS
What is this stuff, and why isn't it wrapped in any sort of
platform-specific test? If it's needed, why is it in only one .c file?
Also, haven't you broken SOCK_STRERROR for the Windows case?
regards, tom lane
Tom,
Tom Lane writes:
Lee Kindness <lkindness@csl.co.uk> writes:
+ #define _THREAD_SAFE + #define _REENTRANT + #define _POSIX_PTHREAD_SEMANTICSWhat is this stuff, and why isn't it wrapped in any sort of
platform-specific test? If it's needed, why is it in only one .c
file?
It's actually in libpq-int.h too... The correct way for this is to
compile with the compilers specific thread flags, however the downside
to this has already been discussed. Depending on the system one, or a
combination of those flags will turn on some magic such as errno being
a function call rather than a global variable. This is needed to make
the library thread safe.
On a second look libpq-int.h isn't the best place for this (hence it
also appears in one of the C files), it needs to be done in each C
file before any of the system headers are included - a libpq-threads.h
header? Would this be ok?
Do do things 100% right we'd need to detect compiler thread flags and
compile with them...
Also, haven't you broken SOCK_STRERROR for the Windows case?
Sorry, I seem to have forgotton to update the prototype in win32.h to
match the updated function. Updated diff attached (and online).
Lee.
Attachments:
diffs-libpq.txtapplication/octet-streamDownload+302-147
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.
AC_TRY_RUN tests are prohibited. Also, try to factor out some of these
huge tests into separate macros and put them into config/c-library.m4.
And it would be nice if there was some documentation about what was
checked for. If you just want to check whether gethostbyname_r() has 5 or
6 arguments you can do that in half the space.
--
Peter Eisentraut peter_e@gmx.net
Ok guys, I propose that the new libpq diff and 2 source files which
i'll soon send to pgsql-patches is applied to the source. This diff is
a cleaned up version of the previous version with the wrapper
functions moved out into their own file and more comments added. Also
the use of crypt_r() has been removed (not worth the effort), the
cpp defines have been renamed to be consistent with each other and
Tom's concerns with loose #defines has been partly addressed.
This diff does not include any configure changes. I plan to tackle
this separately ASAP, and hopefully produce something more acceptable.
I will add checks for appropriate compiler thread flags (for compiling
libpq, and alow the removal of #defines in libpq-reentrant.h), and
link flags & libs (for a planned threaded libpq test program and
renentrant ecpg library). If a thread environment is found then check
for the reentrant functions will be done.
Looking at various open source projects configure.in files there seems
to be little commonality in the thread test macros (telp gratefully
accepted!), I currently think that something like the approach used by
glib is most suitable (switch on OS).
All sound acceptable?
Thanks, Lee.
Peter Eisentraut writes:
Show quoted text
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.AC_TRY_RUN tests are prohibited. Also, try to factor out some of these
huge tests into separate macros and put them into config/c-library.m4.
And it would be nice if there was some documentation about what was
checked for. If you just want to check whether gethostbyname_r() has 5 or
6 arguments you can do that in half the space.
Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
files for src/interfaces/libpq.
Also at http://services.csl.co.uk/postgresql/
Thanks, Lee.
Lee Kindness writes:
Show quoted text
Ok guys, I propose that the new libpq diff and 2 source files which
i'll soon send to pgsql-patches is applied to the source. This diff is
a cleaned up version of the previous version with the wrapper
functions moved out into their own file and more comments added. Also
the use of crypt_r() has been removed (not worth the effort), the
cpp defines have been renamed to be consistent with each other and
Tom's concerns with loose #defines has been partly addressed.This diff does not include any configure changes. I plan to tackle
this separately ASAP, and hopefully produce something more acceptable.I will add checks for appropriate compiler thread flags (for compiling
libpq, and alow the removal of #defines in libpq-reentrant.h), and
link flags & libs (for a planned threaded libpq test program and
renentrant ecpg library). If a thread environment is found then check
for the reentrant functions will be done.Looking at various open source projects configure.in files there seems
to be little commonality in the thread test macros (telp gratefully
accepted!), I currently think that something like the approach used by
glib is most suitable (switch on OS).All sound acceptable?
Thanks, Lee.
Peter Eisentraut writes:
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.AC_TRY_RUN tests are prohibited. Also, try to factor out some of these
huge tests into separate macros and put them into config/c-library.m4.
And it would be nice if there was some documentation about what was
checked for. If you just want to check whether gethostbyname_r() has 5 or
6 arguments you can do that in half the space.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Lee Kindness wrote:
Content-Description: message body text
Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
files for src/interfaces/libpq.Also at http://services.csl.co.uk/postgresql/
Thanks, Lee.
Lee Kindness writes:
Ok guys, I propose that the new libpq diff and 2 source files which
i'll soon send to pgsql-patches is applied to the source. This diff is
a cleaned up version of the previous version with the wrapper
functions moved out into their own file and more comments added. Also
the use of crypt_r() has been removed (not worth the effort), the
cpp defines have been renamed to be consistent with each other and
Tom's concerns with loose #defines has been partly addressed.This diff does not include any configure changes. I plan to tackle
this separately ASAP, and hopefully produce something more acceptable.I will add checks for appropriate compiler thread flags (for compiling
libpq, and alow the removal of #defines in libpq-reentrant.h), and
link flags & libs (for a planned threaded libpq test program and
renentrant ecpg library). If a thread environment is found then check
for the reentrant functions will be done.Looking at various open source projects configure.in files there seems
to be little commonality in the thread test macros (telp gratefully
accepted!), I currently think that something like the approach used by
glib is most suitable (switch on OS).All sound acceptable?
Thanks, Lee.
Peter Eisentraut writes:
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.AC_TRY_RUN tests are prohibited. Also, try to factor out some of these
huge tests into separate macros and put them into config/c-library.m4.
And it would be nice if there was some documentation about what was
checked for. If you just want to check whether gethostbyname_r() has 5 or
6 arguments you can do that in half the space.
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
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 19073Lee, I have a question about this code:
char *pqStrerror(int errnum, char *strerrbuf, size_t buflen)
{
#if defined HAVE_STRERROR_R
/* reentrant strerror_r is available */
strerror_r(errnum, strerrbuf, buflen);
return strerrbuf;
#elif defined HAVE_NONPOSIX_STRERROR_R
/* broken (well early POSIX draft) strerror_r() which returns 'char *' */
return strerror_r(errnum, strerrbuf, buflen);
#else
/* no strerror_r() available, just use strerror */
return strerror(errnum);
#endif
}
Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just
use the HAVE_STRERROR_R code in all cases?
---------------------------------------------------------------------------
Lee Kindness wrote:
Content-Description: message body text
Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
files for src/interfaces/libpq.Also at http://services.csl.co.uk/postgresql/
Thanks, Lee.
Lee Kindness writes:
Ok guys, I propose that the new libpq diff and 2 source files which
i'll soon send to pgsql-patches is applied to the source. This diff is
a cleaned up version of the previous version with the wrapper
functions moved out into their own file and more comments added. Also
the use of crypt_r() has been removed (not worth the effort), the
cpp defines have been renamed to be consistent with each other and
Tom's concerns with loose #defines has been partly addressed.This diff does not include any configure changes. I plan to tackle
this separately ASAP, and hopefully produce something more acceptable.I will add checks for appropriate compiler thread flags (for compiling
libpq, and alow the removal of #defines in libpq-reentrant.h), and
link flags & libs (for a planned threaded libpq test program and
renentrant ecpg library). If a thread environment is found then check
for the reentrant functions will be done.Looking at various open source projects configure.in files there seems
to be little commonality in the thread test macros (telp gratefully
accepted!), I currently think that something like the approach used by
glib is most suitable (switch on OS).All sound acceptable?
Thanks, Lee.
Peter Eisentraut writes:
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.AC_TRY_RUN tests are prohibited. Also, try to factor out some of these
huge tests into separate macros and put them into config/c-library.m4.
And it would be nice if there was some documentation about what was
checked for. If you just want to check whether gethostbyname_r() has 5 or
6 arguments you can do that in half the space.
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
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 19073Your call, but the "broken" call is in earlier glibc versions for
sure (if you're on a Linux box take a look in /usr/include - the
prototype is still there, may even get used depending on compiler
options!). I seem to remember compiling this on recent Solaris, HPUX,
Linux and AIX versions without hitting the "broken" version, but...
L.
Bruce Momjian writes:
Show quoted text
Lee, I have a question about this code:
char *pqStrerror(int errnum, char *strerrbuf, size_t buflen)
{
#if defined HAVE_STRERROR_R
/* reentrant strerror_r is available */
strerror_r(errnum, strerrbuf, buflen);
return strerrbuf;
#elif defined HAVE_NONPOSIX_STRERROR_R
/* broken (well early POSIX draft) strerror_r() which returns 'char *' */
return strerror_r(errnum, strerrbuf, buflen);
#else
/* no strerror_r() available, just use strerror */
return strerror(errnum);
#endif
}Why do we have to care about HAVE_NONPOSIX_STRERROR_R? Can't we just
use the HAVE_STRERROR_R code in all cases?---------------------------------------------------------------------------
Lee Kindness wrote:
Content-Description: message body textPatch attached, along with new libpq-reentrant.c and libpq-reentrant.h
files for src/interfaces/libpq.Also at http://services.csl.co.uk/postgresql/
Thanks, Lee.
Lee Kindness writes:
Ok guys, I propose that the new libpq diff and 2 source files which
i'll soon send to pgsql-patches is applied to the source. This diff is
a cleaned up version of the previous version with the wrapper
functions moved out into their own file and more comments added. Also
the use of crypt_r() has been removed (not worth the effort), the
cpp defines have been renamed to be consistent with each other and
Tom's concerns with loose #defines has been partly addressed.This diff does not include any configure changes. I plan to tackle
this separately ASAP, and hopefully produce something more acceptable.I will add checks for appropriate compiler thread flags (for compiling
libpq, and alow the removal of #defines in libpq-reentrant.h), and
link flags & libs (for a planned threaded libpq test program and
renentrant ecpg library). If a thread environment is found then check
for the reentrant functions will be done.Looking at various open source projects configure.in files there seems
to be little commonality in the thread test macros (telp gratefully
accepted!), I currently think that something like the approach used by
glib is most suitable (switch on OS).All sound acceptable?
Thanks, Lee.
Peter Eisentraut writes:
Lee Kindness writes:
Patches attached to make libpq thread-safe, now uses strerror_r(),
gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
strtok() was previously used strchr() is now used.AC_TRY_RUN tests are prohibited. Also, try to factor out some of these
huge tests into separate macros and put them into config/c-library.m4.
And it would be nice if there was some documentation about what was
checked for. If you just want to check whether gethostbyname_r() has 5 or
6 arguments you can do that in half the space.[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
-- 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
