Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

Tom Lane wrote:

>Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
>
>
>>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().
>
>
Ok. Ahm. No, wait. libpq is multi-threaded, right?

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