Have been looking into this more. Here is a revised patch which also
gets rid of readfdp, writefdp, readfd, and writefd from
Curl_transfer_keeper, as all seem obviated by the new Curl_select()
call.

I also removed from the docs the stipulation that the callers of
curl_multi_fdset() must not remove the fdset after the call. This is
no longer true for fdsets made via Curl_single_fdset(). I've looked
through the various Curl_fdset() functions and it seems to apply to
these also, but I may be missing some special case.

I'm still vague on this, but I wonder if there was a bug in the
interaction between transfer.c and multi.c up until the Curl_select()
patch. In multi.c, curl_multi_fdset() would call Curl_single_fdset()
for each curl easy handle, passing in the read/write/exception fd_sets
provided by its caller. Then Curl_single_fdset() would set its
connection's keep.readfdp and keep.writefdp to point to the fdsets
provided to the multi interface, despite these actually referencing
not just to the fd's of the single connection but all fd's of the
multi connection. Anyhow, now that the fdsets are no longer kept,
this is a moot point, but I am very curious to understand this better.

On Tue, 11 Jan 2005 13:49:27 -0500, Dan Torop wrote:
> In the Curl_transfer_keeper structure, rkeepfd and wkeepfd are set but
> no longer used. ...