> On May 2, 2017, at 5:06 AM, Matt Caswell <matt@xxxxxxxxxxx> 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
