curl-library
Re: curl_multi_fdset ambiguity
Date: Mon, 25 Jan 2010 14:19:38 +0100 (CET)
On Mon, 25 Jan 2010, vick wrote:
> from the documentation on curl_multi_fdset :-
>
> "You should also be aware that when doing select(), you should consider
> using a rather small (single-digit number of seconds) timeout and call
> curl_multi_performregularly - even if no activity has been seen on the
> fd_sets - as otherwise libcurl-internal retries and timeouts may not work as
> you'd think and want.
>
> Starting with libcurl 7.16.0, you should use curl_multi_timeout to figure
> out how long to wait for action"
>
> In the above snippet it is not clear why curl_multi_timeout should be called
> at all. Suppose i see some activity (i.e, max_fd > -1), and i simply call
> select with {tv.sec=0,tv.usec=0 or 1}, and sure enough if the select picks
> up the fd_set, i see it otherwise i dont. In other words, why is this
> multi_timeout useful? And if it is, is there a CURLOPT to set it?
I agree that the phrasing is a bit unclear. I'll elaborate:
You don't want "{tv.sec=0,tv.usec=0 or 1}" since then you'll loop far too
often and call libcurl like a maniac and then you'll waste a lot of CPU
without gaining anything extra.
When you use select(), you want that to use as long timeout as possible so
that you let your app sleep as long as possible.
The mentioned "single-digit" seconds up there originates from the time before
we introduced the curl_multi_timeout() function. I'll see if I can update that
explanation after I send off this mail. curl_multi_timeout() is the preferred
way to get the timeout period to use.
A CURLOPT is not needed or possible to use for the timeout, as you want the
timeout extracted for use when calling select() - which is done outside of
libcurl when you use the multi interface.
Do let me know if this still isn't clear!
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2010-01-25