Manfred Spraul <[EMAIL PROTECTED]> writes:
> 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.
I think we should also take a hard look at avoiding the problem by using
MSG_NOSIGNAL on platforms that have it, so that the right things happen
and overhead is minimized whether or not the application knows to do
this. Besides I am not convinced that an app that *wants* SIGPIPE on
some of its output channels could reasonably solve the problem with a
custom signal handler --- how will the handler know which FD the signal
came from?
The difficulty with MSG_NOSIGNAL is in getting libssl to cooperate.
I wonder if we could convince the libssl implementors that MSG_NOSIGNAL
should be used when available in their standard release, or at least
they should provide an option to use it? The alternative would be to
create our own BIO for libssl, which I think is doable, but would likely
be a pain in the neck to maintain.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
