On Fri, 20 Mar 2009, Nelson B Bolyard wrote:
It would be inappropriate for NSS to defeat sigpipe's signal handler. The handling of that signal is the responsibility of the application, or code at a higher level than NSS. Perhaps it would be appropriate for libcurl to do that.
SIGPIPE is a signal and signals are dreaded in multi-threaded apps in general. What useful purpose does it serve the users of NSS?
libcurl protects all its own uses of socket functions against generating SIGPIPE, and it makes all libraries it use to do the same to the extent they allow. Mostly because we don't see any point in them. If NSS had a way to make them stop, libcurl would use it. Does it?
And if its "inappropriate for NSS to defeat sigpipe's signal handler", why isn't it the same for libcurl? And if it is, the responsibility comes to the application and then you get the mix of signals and threads.
-- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
