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
(inparticular libpq and ecpg)> > thread-safe - that is they can safely be used by a program which> > itself is using
mutliplethreads. I'm largely there with ecpg (globals> > are protected, a sqlca for each thread), but of course it
relieson> > libpq which needs work to share a connection between thrreads.> > AFAIK, libpq is thread-safe already, it's
justnot thread-aware.> What you'd presumably want is a wrapper layer that adds a mutex to> prevent multiple threads
frommanipulating 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
thelibraries will> > need to link to libpthread too. Will this be accepted in a patch?> If the patch requires pthread
andnot any other form of thread support,> probably not. See nearby threading thread ;-)> In general I'd be unhappy
withdoing 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.
