On Wed, 3 Nov 2010, Philippe Le Rohellec wrote:
I'm using libcurl in a multithreaded library running on a variety of
platforms. Recently I ran into the issue described here:
http://curl.haxx.se/mail/lib-2008-06/0183.html : SIGPIPE received through
openssl. This is on Solaris, which does not support MSG_NOSIGNAL.
Solaris is stupid to not offer any decent way to precvent SIGPIPE to happen
other than to explicitly tell it that we ignore it when it occurs.
I take this bug report as evidence that there really doesn't exist any way:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6313487
So the only way to block the SIGPIPE is to allow curl to ignore it in
transfer.c:
You can also ignore it in your app.
But for that to work, CURLOPT_NOSIGNAL must NOT be set, otherwise
"if(!data->set.no_signal)" will fail.
The problem is, if I don't set CURL_NOSIGNAL, it will cause multithreaded
related problems with SIGALRM because CURLOPT_NOSIGNAL is also used in
hostip.c to set a SIGALRM based timeout on DNS queries.
That got me thinking that those 2 uses of CURLOPT_NOSIGNAL are conflicting
and have no real reason to be bundled together: if I set it to 1, I might
get SIGPIPEs and if set it to 0 I might have troubles with SIGALRM.
Ideally, I would prefer to have 2 separate options, 1 would be
CURLOPT_BLOCKSIGPIPE and the second one would be CURLOPT_USESIGALRM. In my
environment, I would set the former to 1 and the latter to 0.
Was this ever considered in the past? If not, why?
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.
The thinking behind CURLOPT_NOSIGNAL has been that it makes libcurl completely
avoid tampering with signals and signal functions. It is usually because apps
are multi- threaded (and then all sorts of signal use usally mess things up)
or that the app itself is in control of what signals it desires and doesn't
what libcurl to interfere.
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'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.
I can also see how we should extend the documention for CURLOPT_NOSIGNAL to
include details on the current SIGPIPE handling.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
