On Mon, 14 Feb 2011, amit paliwal wrote:
I read the use of this two options and I can use them in my multi threaded application so that CURLOPT_TIMEOUT does not send a signal.
Correct.
The words in the document confused me little bit and I just want to make it confirm that, if I use these two options than no other signal BUT SIGPIPE will be sent.
If you use CURLOPT_NOSIGNAL set to 1, libcurl will not use any signal-related functions. It will not _cause_ signals to get sent (using alarm()) to abort slow operations and it will not set up any signal handler that ignores signals that is received.
1) If timeout happens CURL will not make OS send SIGALRM rather it will come out of say curl_easy_perform(), which suits multi threaded applications.
If you use the synchronous resolver, the effect is that there's no effective way to timeout a very slow name resolve.
2) But still, if curl_easy_perform() to write on the socket is under process and the connection where it want to write() is shut down, then CURL will send the SIGPIPE signal.
Almost. The SIGPIPE signal is not sent by libcurl, it is sent by the operating system kernel and yes it can be sent if libcurl tries to send data on a connection that is closed already by the peer. But libcurl tries to avoid that by using MSG_NOSIGNAL and similar on systems that support them, so that it rather returns an error code instead of that silly annoyance that SIGPIPE is...
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
