Daniel Stenberg wrote:

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

The method call I use for things like this looks like:

 /** Updates the file descriptors which need to be selected on
    * for this endpoint.
    */
   virtual void updateFdset(fd_set & input_set, fd_set & output_set, fd_set & exc_set, int& max_desc, uint64& now);

Later I will ask this class if it needs to read/write, and if so, I'll pass in the
fd_sets and that class can check to see if any of the FD's it's interested in are
set in the fd_sets.

NOTES: There are exactly 3 fd_sets and one select loop in the entire program,
they are just passed around by reference where needed.

Ben

-- 
Ben Greear <greearb_at_candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear