libpq questions...when threads collide
От | Don Baccus |
---|---|
Тема | libpq questions...when threads collide |
Дата | |
Msg-id | 3.0.1.32.19991212141847.010487e0@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] LONG (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] libpq questions...when threads collide
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
I'm working on bullet-proofing AOLserver's postgres driver. I've fixed a bunch of weaknesses, but am stumped by the following... AOLserver's a multithreaded server, and libpq's database connection routines aren't threadsafe. It turns out the environment in which the driver lives doesn't allow me to ensure that only one thread executes a PQsetdb at a time, at least without resorting to the specific operating system's mutexes and cond primitives. The server provides a nice portable interface for such things but they're not available to database drivers because in general the server's not interested in having database drivers do such things. That's not a problem for this group, but I'm curious. People have been using this driver for years, and some use it heavily (Lamar Owen, for one). Despite the thread unsafeness of PQsetdb et al, I've never seen a failure in this environment and I've never heard of folks experiencing such a failure. So my question's simple - what exactly makes PQsetdb et al thread unsafe? I'm asking in order to attempt to get a handle on just how vulnerable the routines are when two threads attempt to open a database connection simultaneously. The other question's simple, too - are the implications predictable, i.e. will (for instance) one of the attemps simply crash or fail when two or more threads attempt to make a connection? Or am I looking at something more evil, like silent building of a connection messed up in some subtle way? I suspect the answer to the last question is that the result of doing this is unpredictable, but thought I'd ask. AOLserver supports external drivers called by a proxy with a separate process provided for each database connection, but there are unfortunate performance implications with this approach. It's designed explicitly for dbs with no threadsafe C API. This includes Sybase, and in my testing the internal Postgres driver can feed bytes to the server about three times as fast as the external driver written for Sybase, so you can see why I'm reluctant to rewrite the Postgres driver simply because building a connection's not threadsafe. After all, unless a backend crashes they only happen when the server's first fired up. And people aren't seeing problems. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
В списке pgsql-hackers по дате отправления: