On Thu, 15 Feb 2007, Bryan Henderson wrote:

> It ought to be possible to interrupt curl_easy_perform() with a signal.
>
> There are a number of places curl_easy_perform() takes a long time, but the
> one I'm focussing on right now is where it waits for the server to respond.
> This is a select() call in Transfer() that waits for data to arrive on a
> socket, among other things.

libcurl should never wait on a select() for more than 1000 milliseconds. Any
such occurances present are remaining bugs. As it should then call the
progress callback and then go back to wait more...

> The only hard part of this is that you have to make sure the process doesn't
> receive a signal after the progress callback and before the select(),
> because then there would be nothing to interrupt the select. That can be
> done by blocking signals except when select() is waiting, and that is what
> pselect() is for. It might also require a slight movement of where progress
> callbacks happen.
>
> Does this sound like a viable thing?

Sure, I don't see any harm in this and it can in fact provide added
responsiveness.

[pselect]

> It is a relatively recent addition to POSIX; there are probably systems that
> don't have it. On such a system you can emulate it with sigaction() and
> select(), but that leaves a tiny window in which the process might miss a
> signal and wait anyhow. With older Linux kernels, pselect() actually has
> that same window exposed. Note that isn't any worse than libcurl's present
> logic, in which it _always_ waits in spite of receiving signals.

Yeah, we want libcurl to remain working on system it runs on today so we do
need a version for non-pselect() systems as well.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html