Re: interruptible curl_easy_perform()
Date: Thu, 15 Feb 2007 22:30:34 +0100 (CET)
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
> 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.htmlReceived on 2007-02-15