> On May 2, 2017, at 5:06 AM, Matt Caswell <[email protected]> wrote:
>
>> Yes, ours is a library and we do not wish to ignore the signal process
>> wide because the consumer of our library (application) might want to
>> handle the SIGPIPE for there own socket handling.
>
> Could you use pthread_sigmask() to only block SIGPIPE for the current
> thread (perhaps unblocking it again before returning control back to the
> caller of your library)?
Presumably, the signal will be delivered as soon as it unblocked, and likely
before "returning control to the caller". So I think this just delays the
problem, but does not fix it. Blocking a signal is not the same as ignoring
it. Multi-threaded programs should avoid having signals delivered to some
random thread that happens to be "on CPU", by blocking signals permanently
in all but a single signal-handling thread, but such design decisions are
made in main() and not in libraries.
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
