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/Ex
function 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.
No it won't. It took me ages to figure that one out the hard way ;)