On Mon, 31 Jan 2005, Jamie Lokier wrote:

> Yes, I agree. That's what I'd do. But Daniel does not seem to like
> callbacks, so an array of changes is just as good algorithmically.

I don't mind callbacks in general, I just don't see them fit into this very
comfortably.

I think of an application's main loop looking like this:

   while(still_things_to_do) {
     curl_multi_sock(args...); /* get file descriptors */
     set_things_up(); /* prepare for poll/select/similar */
     select() or poll() or similar(); /* waits on 10000 connections */
     curl_multi_perform();
   }

Of course curl_multi_sock() could be made to call a callback for what file
descriptors that are added/removed from the previous call. If that is what
people in general prefer.

If we're talking details, how do you suggest the specific function
prototype(s) would be? And how can we adjust the API and the simple example
above to as good as possible be prepared for a huge amount of connections?

> Now that Dan's redesigning curl_fdset it seems appropriate to pick a design
> that isn't limited in a known way.
>
> After all, the whole point of this new API is to get around an earlier known
> limitation... may as well do it properly.

I fully agree with this, and I'm appreciating this discussion a lot. We should
design the new API with all eyes wide open.

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