From: Andrew Schweitzer (a.schweitzer.grps_at_[hidden])
Date: 2006-01-02 21:04:33
Hi Chris, just trying to understand how select_reactor works. Can you
confirm/correct?
select_reactor's job is to wait for socket operations and timeouts. When
any of these occur, select_reactor calls demuxer::post so that
demuxer_service to can actually issue the callbacks for these events.
select_reactor does its job by calling select.
Select is passed a list of all active sockets plus a special, "dummy"
socket. Select_reactor, via a socket_select_interrupter object, is both
client and server on this special dummy socket.
When the user wants to add a new event to react to, select must be
interrupted so it can start waiting on the new event. This is
accomplished by issuing a write on the dummy socket.
If the user has scheduled any timers, select is passed a timeout of the
smallest existing timer.
On Windows select_reactor constructor starts its own thread which
executes the select wait in a loop.
Assuming all of that is correct, can you explain what the code in
socket_ops::select() does that checks if all sockets are null and if so
calls ::Sleep()? I sort of expect I've missed something, but it looks
like dead code. with the prescence of the interrupter and its dummy
socket, the socket list will never be null. Also, if they were null, I'm
not sure Sleep would work very well. For one thing, it's not
interruptable, so if the only thing is a large timer, any new additions
of sockets or timers would have to wait for the large timer to complete
before they could be added. For another, it looks like if there were no
timers running, it would essentially be polling 1/ms for sockets +
timers.
Thanks,
Andrew