GetQueueCompletionStatusEx

[Alan Bateman]

John Davis wrote:
> Forgot the CC
>
> On Thu, Dec 31, 2009 at 11:01 AM, John Davis <jdavis at pcprogramming.com 
> <mailto:jdavis at pcprogramming.com>> wrote:
>
>     I'm not an expert on the nio internals.  My thinking is it would
>     be nice if everything could be done with a single thread (ie all
>     reads/writes on all handles are async and pumped thru IOCP). 
>     Because the kernel context switch overhead is pretty much
>     eliminated with this call, there is no longer a need to have a
>     thread pool to handle the context switch overhead.  We also
>     wouldn't have the batching dilema with the thread pool gone.  Only
>     problem with this model is that there's no way to guarantee a
>     completion handler won't block.
>
You can use a single thread if you wish but aren't you concerned about 
scaling to multiple sockets and cores? However you are right, if the 
channel group's thread pool  has a single thread, then the completion 
results can be retrieved in batch to avoid a call to 
GetQueueCompletionStatus per I/O.

>     :
>     SetFileCompletionNotificationModes, allows the callback to be
>     invoked immediately, rather than pumping thru IOCP and thread pool.
>
We can certainly try the FILE_SKIP_SET_EVENT_ON_HANDLE mode to see if it 
makes a difference but for now we can't really make use of the 
FILE_SKIP_COMPLETION_PORT_ON_SUCCESS mode. Our implementation can 
actually immediate case we have it disabled at this time. The reason is 
that under load conditions, for loopback connections at least, the 
number of bytes transferred, as returned by WSARecv/WSASend is not 
reliable. We therefore require the completion result so that we can 
update the buffer position and notify the completion handler with the 
correct result.

-Alan.