On Tue, 12 Mar 2013, Kamil Dudka wrote:

> The fact that libcurl received SIGPIPE while executing its code does not
> necessarily mean that the signal was caused by libcurl.

Ah, you mean like if you do things within callbacks etc and you'd like the
signal then?

> There should be a way to disable the "ignore SIGPIPE" feature. What about
> using the CURLOPT_NOSIGNAL option to control this?

I think there's an all-or-nothing problem with cramming all signal related
things into a single option that some users have been hit with. I mean you may
for example still like to abort slow async name resolves (using signals) while
you don't want spurious SIGPIPE when calling a libcurl function...

(In my view, SIGPIPE was always a bad idea and should never be used.)

> It seems to be already documented such:

Very true, by acknowledging that bit we would adhere to the existing
documentation. I'll adjust the patch to do just that, and then we can continue
thinking about and debate wether we need another option or not for more
fine-grained signal control.

Thanks!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html