On Mon, 29 Oct 2001, Steve Dekorte wrote:

> > 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().
>
> I was just offering it as an example of the simplest code.

Ah, ok. Sorry for my quick (but wrong) conclusions!

> ...application run loop...
> {
> ...other stuff...
> curl_select_perform(select_handle); // handle all curl handles with
> waiting data without blocking
> }
>
> > 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.
>
> I don't see any reason to provide the info in curl_select_extract. The
> only thing it's information is useful for is doing what
> curl_select_perform() does for you. Or is there something I'm missing?

The reason for getting the fd_set variables from curl (as I just updated my
"draft" says after Ben Greear's recent comments) would be to allow the
application to use select() properly to wait for input/output on both its own
and curl's file descriptors:

 while (loop ) {

     curl_select_fdset(select_handle,
                       &readfd, &writefd, &expfd,
                       &maxfd);

     /* Add our own appliction specific file descriptors here. */

     result = select(maxfd+1, readfd, writefd, expfd, timeout);

     switch(result) {
     case blabla:
       /* one of curl's handles were ready */
       curl_select_perform(select_handle);
       break;
     }

 } /* loop until done */

The application could then choose to use the fd_sets from curl, or it can
choose to ignore them and just call curl_select_perform() whenever it thinks
it might be time for curl to do something.

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