IOCP on Windows would use a thread pool to dispatch work after async sockets come due for some action. And after work for any given socket is completed, it's possible for work to start on a different socket's completion, with the "context switch" (or rather, continuation callback) happening in userland, rather than requiring a context switch. This inversion of control acts a bit like work stealing.
LIFO is also the strategy for Completion Ports in Windows:
> Threads that block their execution on an I/O completion port are released in last-in-first-out (LIFO) order, and the next completion packet is pulled from the I/O completion port's FIFO queue for that thread. This means that, when a completion packet is released to a thread, the system releases the last (most recent) thread associated with that port, passing it the completion information for the oldest I/O completion.
Yes; but it's for the duration of work on that completion, it's not like sockets are owned by the thread, so it doesn't have the same misbalancing effect, where if the original thread is not available completions get starved. The LIFO nature is a side effect of the user mode selection of next completion to run; something round robin would be slower with kernel transitions.
