[Live-devel] win select() problem
Ross Finlayson
finlayson at live.com
Thu Oct 28 10:01:07 PDT 2004
>I noted that when you arrive here:
FYI, you're referring to "BasicTaskScheduler::SingleStep()"
> while ((handler = iter.next()) != NULL) {
> if (FD_ISSET(handler->socketNum, &readSet) &&
> FD_ISSET(handler->socketNum, &fReadSet) /* sanity check */ &&
> handler->handlerProc != NULL) {
> (*handler->handlerProc)(handler->clientData, SOCKET_READABLE);
> }
>
>variables readSet and fReadSet are different
That's correct. "fReadSet" is the actual set of readable sockets (i.e.,
for which we have a handler function). It is copied to "readSet" before
"select()" is called. The "select()" call then modifies "readSet" to be
the subset of those readable sockets on which there are currently data
available. Note: from "man select":
"On return, select() replaces the given descriptor sets with
subsets consisting of those descriptors that are ready for the requested
operation."
That's why "readSet" is tested. Note, however, that - as a sanity check -
we also test "fReadSet", to make sure that a socket marked by "select()" as
having available data was really one of the readable sockets. I.e., we
test that "readSet" (as set by "select()") really is a subset of "fReadSet".
> so when you have to handle rtcp socket, it doesn't find it in readSet
If this is the case, then your OS's implementation of "select()" is broken.
The current code is correct.
Ross Finlayson
LIVE.COM
<http://www.live.com/>
More information about the live-devel
mailing list