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