[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