On Thu, 10 Mar 2005, Jamie Lokier wrote:

>> You mean like a maximum time we can allow the app to wait without action
>> before it should call curl_multi_socket() anyway?

...

> You should ensure the calculation is quite efficient - you'll have a
> priority queue of timeouts

Yes. But my first and main priority right now is to make sure the API doesn't
prevent a smart underlying implementation. I don't think I'll actually do the
smart implementation now. I'll save that for an upcoming rainy day. :-)

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

Okay, I'm convinced. So if we add a timeout parameter to the callback as well,
we can let the app do the timeout work if it wants and has the power, or it
can call curl_multi_timeout() to get it from libcurl. Goodness?

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

Hehe, here I go thinking that I'm closing in and then you come throwing in
these new good ideas and I have to rethink and edit my suggestion even more!
;-)

You are just so right. There simply is no good reason for two separate
function calls as they can be one unified instead, which should make life
simpler for apps that use this.

My latest updated suggestion is now available here:

         http://curl.haxx.se/dev/curl_multi_socket

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html