Manfred Spraul <[EMAIL PROTECTED]> writes:Ok. Ahm. No, wait. libpq is multi-threaded, right?
Is that really necessary?
Unfortunately, yes. libpq can't change the global setting of SIGPIPE
without breaking the surrounding application, but we don't want to crash
the app if the server connection has disappeared, either. So we have to
set the SIGPIPE handler and then restore it around every send().
signal handlers are a process property, not a thread property - that code is broken for multi-threaded apps.
At least that's how I understand the opengroup man page, and a quick google confirmed that:
http://groups.google.de/groups?selm=353662BF.9D70F63A%40brighttiger.com
I haven't found a reliable thread-safe approach yet:
My first idea was block with pthread_sigmask, after send check if pending with sigpending, and then delete with sigwait, and restore blocked state. But that breaks if SIGPIPE is blocked and a signal is already pending: there is no way to remove our additional SIGPIPE. I don't see how we can avoid destroying the realtime signal info.
Mark: Is your dbt2 testapp multithreaded? I don't see the signal functions near the top in the profiles on the osdl website.
-- Manfred
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
