On 11/03/2010 11:52 AM, Daniel Stenberg wrote:
> It has not been considered before because nobody has brought it up until now.
> I guess this is because most users either run OSes where this isn't a problem
> or they don't set CURLOPT_NOSIGNAL.
Actually, it might happen on all Unix platforms in situations where
openssl is triggering the SIGPIPE. In those situations, MSG_NOSIGNAL
doesn't protect us even on OSes where it's supported. That's an openssl bug.
> The generating of SIGPIPE from system calls is a feature we work hard to avoid
> as it only messes up our API and I believe it rarely offers much goodness.
I agree.
> I'm a little shocked that Solaris doesn't have a decent API for this so yes I
> can understand why you want a CURLOPT_BLOCKSIGPIPE option. But why can't you
> simply not do this in your app then instead? It is just as impacting when done
> there, right? And it could be made to work right now without any modifications
> needed to libcurl.
The reason I can't do it is because I'm just implementing a library that
various applications will link with, so I'm not at liberty to mask the
SIGPIPE globally, maybe the application will want to handle it
differently in contexts other than curl (I agree it's unlikely but who
knows).
I guess I could do it to the same way it's done in transfer.c around
every call to curl_easy_perform in my library but that's potentially a
lot of places.

In any case, thanks for your answer. If you ever decide to split the
CURLOPT_NOSIGNAL option, let me know, I would find it very useful.

Philippe
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-11-03