On Tuesday, March 12, 2013 08:26:30 Daniel Stenberg wrote:
> 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?

Exactly. If you are feeding another process, which suddenly disappears, the
signal comes asynchronously to the execution of libcurl-based application.
Then, if the application relies on receiving the signal (which is probably
not the best approach), it may become non-responsive in case the signal is
lost.

> > 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...

I agree, but a coarse control of this is better than no control in my view.

> (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.

On Tuesday, March 12, 2013 08:45:38 Daniel Stenberg wrote:
> On Tue, 12 Mar 2013, Daniel Stenberg wrote:
> > I'll adjust the patch to do just that
>
> Here's an updated version of the patch that takes the CURLOPT_NOSIGNAL
> option into account.

Looks good to me.

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