On Sat, 27 Oct 2001, Steve Dekorte wrote:

[Continuing talk about the API brainstorming and example application source
code found here: http://curl.haxx.se/dev/new-API.txt, this is a reply to two
different mails in one!]

> I was thinking this middle bit would look like:
>
> {
> while(curl_select_count(select_handle)!=0)
> { curl_select_perform(select_handle); }
> /* this way curl_select_extract isn't needed */
> }

Why busy-loop like that? If you want a "pull" interface it is generally
because you wanna do other things as well while transfering data with curl.
Then you'd probably do that with your own select(). If you don't want to do
your own stuff, I think the above could instead be turned into:

  curl_select_run(select_handle);

... that would block until all the selected transfers are done. Or am I
wrong? We could also use this function to support getting "custom" file
descriptors to curl, that when there's data available or the fd is ready for
writing, curl would call a callback for the application to do whatever it
wants.

In fact, with my suggested interface we can use your approach as well. You
just call the curl_select_perform() either when you know there's data on one
of curl's file descriptors or when you think it would be good to let curl
figure that out itself. curl_select_count() in your example gets the same
information as the curl_select_extract() does in my example (only a little
less detailed).

> void my_handle_callback(curl_handle, message, data)
> {
> if (message == FINISHED)
> { curl_select_remove_handle(select_handle, curl_handle); }
> /* maybe curl_select_perform should take care of removing the
> handle? */
> }

Ah, that's a good point to what kind of callback/feature we might need. It
would solve the issue I raised in my application example.

Ben Greear wrote in a separate mail:

> I think the API should be: curl_deal_with_fd_set(fd_set fds). That way the
> users don't have to know which FDs in particular belong to curl, and curl
> can just ignore any FDs that it doesn't own. The entry point is just after
> the normal curl select (I imagine), so it should not disrupt the
> architecture too badly.

(Ok, that function is named curl_select_extract() in my API blurb document.)

Ah, that might be an idea, yes. It would of course also require that the
function returns the highest file desrciptor in use, as that is what any user
of select() would be interested in (select's first argument).

Thinking about it, I'm not sure it is possible/portable to merge one fd_set
with another one. The functions FD_SET, FD_CLR and FD_ISSET all operate on
single FDs on the fd_set type. We might need to use plain FDs to make it work
everywhere.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/