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