cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] suggested SIGPIPE handling for libcurl

From: Kamil Dudka <>
Date: Tue, 12 Mar 2013 00:30:01 +0100

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] =

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:

List admin:
Received on 2013-03-12