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
sockets/file handles.

> 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.html