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
Received on 2010-11-03