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.
So the only way to block the SIGPIPE is to allow curl to ignore it in
transfer.c:
#if defined(HAVE_SIGNAL)&& defined(SIGPIPE)&& !defined(HAVE_MSG_NOSIGNAL)
/*************************************************************
* Tell signal handler to ignore SIGPIPE
*************************************************************/
if(!data->set.no_signal)
data->state.prev_signal = signal(SIGPIPE, SIG_IGN);
#endif
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?
Regards.
Philippe Le Rohellec
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
