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

Manfred Spraul <manfred@colorfullife.com>

From: Manfred Spraul <manfred@colorfullife.com>
To: markw@osdl.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org, osdldbt-general@lists.sourceforge.net
Date: 2003-11-04T19:22:43Z
Lists: pgsql-hackers
markw@osdl.org wrote:

>On  1 Nov, Tom Lane wrote:
>  
>
>>Manfred Spraul <manfred@colorfullife.com> writes:
>>    
>>
>>>signal handlers are a process property, not a thread property - that 
>>>code is broken for multi-threaded apps.
>>>      
>>>
>>Yeah, that's been mentioned before, but I don't see any way around it.
>>What we really want is to turn off SIGPIPE delivery on our socket
>>(only), but AFAIK there is no API to do that.
>>    
>>
>
>Will this be a problem for multi-threaded apps with any of the client
>interfaces?
>
>Anyone working on making it threadsafe?
>  
>
The POSIX api is not thread safe: signal handlers are per process, and 
libpq would like to block SIGPIPE for it's send() calls. For single 
threaded apps, libpq just calls sigaction and sets the handler to 
SIG_IGN around the syscalls.
For multithreaded apps, this is not possible: sigaction is per process.
Thus the calling application must handle the SIGPIPE signals for libpq - 
either by blocking or ignoring them. We are still discussing the exact 
API. Probably a global state that is accessible through a new function.

One thread-safe alternative might be the combination of sigprocmask / 
pthread_sigmask and sigwait, but I think this would be too fragile.

--
    Manfred