Re: IOCPs again
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:O%2313Nj04HHA.1992@TK2MSFTNGP03.phx.gbl...
Ben Voigt [C++ MVP] <rbv@nospam.nospam> wrote:
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:eV6GPLy4HHA.1484@TK2MSFTNGP06.phx.gbl...
It is common to maintain additional per-operation state by extending
OVERLAPPED structure with your own fields - like this:
struct OpState {
OVERLAPPED overlapped;
int moreState;
};
I wasn't aware that the API would give you back the same OVERLAPPED*
and not copy the structure internally. Is this documented somewhere?
From the docs on GetQueuedCompletionStatus:
lpOverlapped
[out] Pointer to a variable that receives the address of the OVERLAPPED
structure that was specified when the completed I/O operation was started.
MSDN suggests that user data should be stored in the hEvent field
instead.
It does? My copy says this in OVERLAPPED docs:
hEvent
Handle to an event that will be set to the signaled state when the
operation has been completed. The calling process must set this member
either to zero or a valid event handle before calling any overlapped
functions.
"The ReadFileEx function ignores the OVERLAPPED structure's hEvent member.
An application is free to use that member for its own purposes in the
context of a ReadFileEx call. "
I thought that binding to a completion port also made the hEvent member
available to arbitrary use. I was wrong. The same I/O operation won't
cause both a completion port and hEvent to be set, GetQueuedCompletionStatus
gives the details:
"Even if you have passed the function a file handle associated with a
completion port and a valid OVERLAPPED structure, an application can prevent
completion port notification. This is done by specifying a valid event
handle for the hEvent member of the OVERLAPPED structure, and setting its
low-order bit. A valid event handle whose low-order bit is set keeps I/O
completion from being queued to the completion port."