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