Tom Lane writes:
 > Lee Kindness <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]

Reply via email to