Re: IOCPs again
"SD" <sd@nospamgroup.com> wrote in message
news:41BC92E8-0497-4D84-B9A0-1530EAE221AA@microsoft.com
Yes. Basically, OVERLAPPED pointer uniquely identifies a particular
asynchronous I/O operation. You pass it to, say, ReadFile, and get it
back in GetQueuedCompletionStatus.
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;
};
// or
struct OpState : public OVERLAPPED {
int moreState;
};
So, how is it "overlapped" in that case?
I don't understand this question, sorry.
I though maybe the same
allocated memory is reused in some way making it OVERLAPPED.
I don't understand this statement either.
2. Also, MSDN says that once a handle(like socket) is associated
with an IOCP, it cannnot be used to do ReadFile/ WriteFile
operations. In that case how do you send/ receive data?
Where do you see that? You must have misunderstood something.
In the MSDN documentation for CreateIoCompletionPort, Remarks section.
It says:
"After an instance of an open file is associated with an I/O
completion port, it cannot be used in the ReadFileEx or WriteFileEx
function. It is best not to share such an associated file...."
You do realize that ReadFile and ReadFileEx are two different API
functions, right? ReadFileEx enables a different style of waiting for
asynchronous I/O - asynchronous procedure calls (see SleepEx,
QueueUserAPC et al). It just cannot be used together with completion
ports. You have to settle on one mechanism or the other.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925