Re: interruptible curl_easy_perform()
Date: Sun, 18 Feb 2007 23:41:26 +0100 (CET)
On Sun, 18 Feb 2007, Bryan Henderson wrote:
> Question: Why is poll() preferred? It provides a slightly more capability
> than select(), but libcurl doesn't seem to exploit it.
When using select() we have no way to know properly when too many sockets are
being used and thus buffer-overwriting. With poll() we have no such
limit/buffer problem. It is a real problem for applications that use a lot of
> I note that the code refuses to build on a system that does not have
> select(), even if it uses only poll().
That's a bug, but I doubt there are many systems available that have poll()
but not select()...
> 2) libcurl does not call the user's progress function if it already called
> it within the same second. The comment indicates that it really just wants
> to avoid updating speed measurements more than once a second. So I changed
> the code so it just skips the recalculations if it has already done them
> within the same second. The progress function may be called twice in the
> same second, and the builtin progress meter may run twice in the same second
> as well.
> Is that bad? I read in the archives that this callback is supposed to be
> for aborting downloads as well as for displaying progress bars, so it makes
> sense that the requirements of the speed calculations wouldn't control it.
Well, I think I originally made it so to prevent the progress meter output to
get updated very often since it totally unnecessary. But sure, I could indeed
agree to allowing the user-defined callback to be called a lot more often than
so and just prevent the built-in progress-meter to get displayed faster than
roughly once per second.
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2007-02-18