> As you have stated, the issue of libcurl being able to be signal
> interrupted has popped up several times. Before going deeper into 'how
> this should be done' I would quite like to see someone explaining why
> it is actually needed in the library and why that need can not be
> satisfied using libcurl with properly set timeout values.

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.

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.

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.

Currently, the PROGRESSFUNCTION callback can be used in place of a
possible INTERRUPTFUNCTION with a latency of one second, but only when
the transfer state has been established. And, as a developper, I would
still be reluctant to divert it from its purpose.

I hope this makes things clearer.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."