Daniel Stenberg wrote:
> You mean like a maximum time we can allow the app to wait without action
> before it should call curl_multi_socket() anyway? I've been intending to
> add such a function before, and maybe the time has come now... It is useful
> for the existing curl_multi_perform()-using apps as well.

That's best IMHO.

You should ensure the calculation is quite efficient - you'll have a
priority queue of timeouts (for each of the different things in
progress), and you need to calculate the first one efficiently when
there are N timeouts - repeatedly as most of them don't change from
one call to the next.

A linear scan of the list of timeouts is not efficient, and neither is
keeping the list sorted by inserting with a linear scan.

A heap-ordered priority queue is ok, though not theoretically optimal
in the case that most timeouts are removed before they'd be triggered.

> I don't see how it can be useful with a timeout in each socket callback
> call?

It would move the burden of sorting the many pending timeouts from
libcurl to the application's event loop.

Any application with a "scalable" event loop (e.g. using one of the
system calls that's faster than select/poll), should also have a
"scalable" timer data structure - one that can calculate the next
pending timeout from a decent data structure for timeouts which are
likely to be removed before they trigger.

So it makes sense to use the application's timeout sorting in that
case.

> >Another option that might be worthwhile considering is having
> >curl_multi_update called only once when initilizing curl, and then curl
> >itself calling the curl_socket_callback when there are changes internally
> >by curl automatically. This avoids on extra call on each loop, and would
> >make curl integrate a lot easier (as well I suspect, have a minor
> >performance boost around the mainloop area, but its *debatable* if the
> >extra overhead for curl to check the socket status at the end of each of
> >its iterations will offset any further performance boost)
>
> The reason I didn't integrate it, is that I was thinking that _always_
> calling the callback on socket changes might cause a lot of extra calls
> since a socket change might get changed again later before the app get a
> chance to wait for anything on it.

Why would it call the callback more often?

Why not, in effect, call curl_multi_update() at the end of each call
to curl_multi_socket(), just before it returns?

In most cases, that will call the callback once per fd, if there have
been any changes for that fd. Occasionally it will call the callback
for a different, related fd (e.g. due to the two sockets for FTP being
related). Either way, that's not likely to call the callback much
more times than a separate curl_multi_update() in the event loop, is it?

-- Jamie
Received on 2005-03-10