2008/3/3, Pierre Ynard wrote:

> I agree that the need is less than obvious if you're calling libcurl
> from a client application. But you may also want to use it within a
> daemon or a more complex service, for example to handle connections
> that will be used as persistant channels. In that case, you will want
> to shut down the daemon properly with a SIGTERM. Also, you may want
> to reload its configuration with a SIGHUP, to change the target URL,
> tweak TCP settings, etc... things that you're all the more likely to
> try when the connection is stalled or failing.

With this I understand that the app might want/need to abort all
libcurl operations currently in progress regain control and finally
call curl_multi_cleanup / curl_easy_cleanup / curl_global_cleanup for
proper tearing down or restarting of the app / daemon.

What will happen if SIGHUP / SIGTERM triggers when openssl / gnutls /
openldap / kerberos / libssh2 / etc code is being executed by libcurl
? Will it make any real difference ? Will libcurl also get the signal
and be able to abort immediately ? Just curious.

> Clearly, you would prefer not to tamper with your timeout settings, and
> you don't want to set your application to stop and retry connections
> every second just so that it gets responsive when an admin comes by.

Timeout settings allow your app/daemon to regain control if connection
cannot be established, its up to the app what it does after that. If
signals are used or not does not impose what the app must do once your
app regains control from the library.

If the app retries every second or manual operator intervention is
needed has nothing to do with signals, nor actually libcurl.

> Also, setting timeouts will basically allow you to abort and get back
> control after some time, but there might be other IPC events related to
> the rest of the application, that you want to handle, but without
> aborting libcurl operations.

In this case libcurl does not care about the signal handlers or IPC
mechanisms you use in your app for other things, and as such libcurl
needs nothing at all.

> I hope this makes things clearer.

I'm sorry, but for me not clear enough yet.

Suppose you had no possibility of seeing libcurl internals, and that
you only had access to libcurl's public API. How would you express the
needs you have relative to the existing API in plain English ?

-- 
-=[Yang]=-