When asynchronous I/O (or "overlapped" I/O in Win32 jargon) is used, we need to deal with the OVERLAPPED structure and his hEvent member. If the I/O function will delay the read or write operation, we will get an ERROR_IO_PENDING error code, then we will wait the asynchronous operation to complete with a WaitForXxxEvent function, then we will call GetOverlappedResult.
However, if the I/O operation is immediately completed, we will not get ERROR_IO_PENDING, and in a read operation our read buffer will be filled immediately. But what about the OVERLAPPED::hEvent member? Will it be set to signaled state? I've not found a clear statement about that.
This question may seem pointless (why deal with the event if I know that the operation is already completed?), however I have a library that mimics the overlapped pattern and I need to have the same exact behavior.
As pointed by edgar.holleis in his comment, Raymond Chen explained this in his blog: http://blogs.msdn.com/b/oldnewthing/archive/2014/02/06/10497096.aspx
If an asynchronous I/O completes synchronously, is the hEvent in the OVERLAPPED structure signaled anyway?
Yes.
When an I/O completes (whether synchronously or asynchronously), the event is signaled and completion status notifications are queued. The
GetOverlappedResult/Exfunction can be used to wait on an I/O that has already completed; it will merely return immediately. If you ask HasOverlappedIoCompleted whether the I/O has completed, and the I/O completed synchronously, it will correctly report, "Yeah, of course it completed. Heck, it completed a long time ago!"In other words, you can logically treat the case of an asynchronous I/O request completing synchronously as if it had completed asynchronously. It just completes asynchronously before you even blinked.
