2008/3/4, Pierre Ynard wrote:

> The need is to regain control of the process flow when it is stuck in
> the middle of a function call well-known to block for some amount of
> time. With classic system calls, any signal will interrupt the call and
> it will return with EINTR. Often, basic pieces of library functions may
> be set to non-blocking mode, so that they never block, thus there is no
> need to worry about interrupting them. More elaborated library
> functions, such as libcurl's easy interface and curl_easy_perform(), do
> handle blocking, and never return until the operation either completes
> or fails. Hence the need to interupt them in some cases.

As a default, any system network function called from inside libcurl
which might be interrupted by a signal somehow should be called again
until it succeeds or it fails without an EINTR.

If the above is not done libcurl might be adversely affected by _any_
signal, whatever a signal is and how widely they are delivered is
system dependant, so the only safe approach for libcurl is to retry
network calls that have been interrupted.

Mostly for fun and internal testing, you can compile libcurl with the
experimental CURL_ACKNOWLEDGE_EINTR defined and functions
Curl_socket_ready() and Curl_poll() won't retry interrupted network
calls, watching how your app behaves on your system with other apps,
for which you have no control, also running.

Once that said and taking in account that the network call will be
retried upon EINTR, you could still want it to fail for some very
specific signal, lets say SIGTERM, how would you do it ?

Remember that libcurl is a library, that it widely used in
multi-threaded environments, and that it might be compiled/deployed as
a shared library and used by different apps on the same system.

-- 
-=[Yang]=-