Re: PostgreSQL libraries - PThread Support, but not use...
От | Lee Kindness |
---|---|
Тема | Re: PostgreSQL libraries - PThread Support, but not use... |
Дата | |
Msg-id | 15897.48344.368755.465399@kelvin.csl.co.uk обсуждение исходный текст |
Ответ на | Re: PostgreSQL libraries - PThread Support, but not use... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL libraries - PThread Support, but not use...
Re: PostgreSQL libraries - PThread Support, but not use... |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: