...Windows doesn't do it this way, although according to the docs
other members of the overlapped structure are modified by Windows.
Ok, we need to rewrite GetOverlappedResult to use the internal
structures (and get the hEvent we might have created in ReadFile),
instead of relying on the one from the overlapped struct itself
I'd rather say it's GetOverlappedResult which is to blame. If the
hEvent is NULL, then we shouldn't return any error (as we do) but
rather assume all wait operation succeed (if hEven is NULL, ReadFile
and WriteFile operations are synchronous, so calling
GetOverlappedResult is a no-op).
This turns out not to be the case. As long as lpOverlapped is
supplied, a NULL hEvent will work fine and allows overlapped reads.
Could you also test it with opening a file (files and sockets semantics
are somehow different)
Ah, I didn't know that. If we keep calling CreateEvent over and over
again with a NULL parameter, will we eventually run out of some
resource? If so, it may still be best to construct a name, since
calling CreateEvent with the same name twice will apparently avoid
creating another event.
if you run out of resource with calling with a NULL parameter, you'll
also get out of resource with constructing the name, so you don't need
to bother here
The attached test program uses overlapped reads with a NULL hEvent in
the OVERLAPPED structure to connect to an IP address and port given on
the command line. Here's an example from Windows:
C:>overlapped-test 216.12.213.139 25
Calling ReadFile
ReadFile returned ERROR_IO_PENDING, as expected
ov .hEvent=00000000
Calling Sleep(2000)
Calling GetOverlappedResult
GetOverlappedresult read 85 bytes:
220 2search2.com ESMTP Sendmail 8.10.2-SOL3/8.10.2; Mon, 17 May 2004 11:58:26
-0400
just for fun, what gives without the Sleep ?
A+
