hEvent member in OVERLAPPED Win32 structure

问题

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 Get­Overlapped­Result/Ex function can be used to wait on an I/O that has already completed; it will merely return immediately. If you ask Has­Overlapped­Io­Completed 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.

回答1:

No it won't. It took me ages to figure that one out the hard way ;)

来源：https://stackoverflow.com/questions/2511690/hevent-member-in-overlapped-win32-structure