OVERLAPPED structure must exist when a successful I / O operation (or manual PostQueuedCompletionStatus () ) is performed until OVERLAPPED arises from a call to GetQueuedCompletionStatus () .
You are responsible for the lifetime of the structure.
In MSDN docs, you'll see that GetQueuedCompletionStatus() actually takes a "pointer to a variable that receives the address of the OVERLAPPED structure that was specified when the completed I / O operation started." What you actually get from this call is a pointer to the original OVERLAPPED that you passed when you made the call to PostQueuedCompletionStatus() (or initiated the I / O overlap operation).
This is all very useful, since the “normal” way to use the OVERLAPPED structure is to put it in a large structure that contains all the information about “every operation” that you may need - so this is an ideal way to navigate directly from a limited the information you give when you call GetQueuedCompletionStatus() , for example, in the data buffer that you used in your overlapping read call ...
I believe that the best way to deal with OVERLAPPED structures is to: a) embed them in the buffer that you use for reading / writing; b) refer to them and c) return them to the pool for reuse when ref count drops to 0.
I have the source code that you can download ( here ), which can make it a little easier to understand (this is a complete IOCP server example so it is a bit complicated, but it works and shows how these things can be used).
source share