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