On 1 Nov, Tom Lane wrote: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.
Manfred Spraul <[EMAIL PROTECTED]> 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?
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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
