On 3/20/09, Daniel Stenberg <dan...@haxx.se> wrote: > > 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 >
His question of does it is exactly my question. Sadly seeing that Firefox itself has at times has shared my exact problem, I am not so confident in fixing: Program received signal SIGPIPE, Broken pipe. [Switching to Thread -1409303664 (LWP 22988)] Does anyone have any knowledge of the status of NSS's broken pipe handling or an alternative approach to handling a sigpipe in ssl and libcurl multi threaded. John
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
