On Monday, March 11, 2013 22:54:26 Daniel Stenberg wrote:
> Hi friends,
>
> In bug #1180 [1], we have a clear case where we get a SIGPIPE and there's
> currently no way for libcurl to deal with it nicely. This is because the
> actual offending write() (or similar) call is made from within OpenSSL. I
> suspect other 3rd party libs we use may be able to do the same thing.
>
> The only work-around we have up until now is to recommend that the libcurl-
> using applications themselves ignore SIGPIPE. That's also what the curl tool
> does now so that it won't die as easily from this problem.
>
> I've written a small patch that shows my suggested fix. It is two functions
> that should be called on libcurl-entry and libcurl-exit for all libcurl
> functions that risk causing a SIGPIPE. The functions will switch on sigpipe
> ignoring and then switch back the "outside's" situation again on exit.
>
> Comments?
>
> [1] = https://sourceforge.net/p/curl/bugs/1180/

The fact that libcurl received SIGPIPE while executing its code does not
necessarily mean that the signal was caused by libcurl. There should be
a way to disable the "ignore SIGPIPE" feature. What about using the
CURLOPT_NOSIGNAL option to control this?

It seems to be already documented such:

https://github.com/bagder/curl/commit/d95b67f4

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-12