[Libevent-users] GetQueuedCompletionStatus return values question/problem

[Toby Douglass]

Rhythmic Fistman wrote:
>> From: Toby Douglass <toby.douglass at summerblue.net>

>> 2. return value != 0 and lpOverlapped == NULL
>>     - all handles associated with the IO completion object have been
>> closed and the IO completion object itself has been closed (time to quit)
> 
> For an lpOverlapped == NULL case I recognise two err codes, WAIT_TIMEOUT
> (common, because you can use a demuxer in poll mode) and
> ERROR_OPERATION_ABORTED.

Yes - I do an infinite wait, so I've not been thinking about 
WAIT_TIMEOUT.  It can happen though, of course.

> This last one I've never seen... I think, or only when someone rudely 
> closes
> the iocp from under the thread calling GetQueuedCompletionStatus, 
> something that
> really shouldn't be done.

I'm not sure that can be the reason.  As I understand it, the IOCP is 
supposed to remain open until all the objects associated with it have 
been closed *and* it itself has been closed.

When this happens, we should be in case 2, return value != 0 and 
lpOverlapped == NULL.

>> 3. return value == 0 and lpOverlapped != NULL
>>     - GetQueuedCompletionStatus() was okay, but we dequeued a *failed*
>> IO operation (note that lpNumberOfBytes is not set in this case)
> 
> Really? What kind of io operation? WSASend/Receive? Connect/AcceptEx?

I presume it mean any IO operation which the IOCP object is getting 
completes for.  So it could be a failed read where the socket doesn't 
close, something like that.  Or something easier to think of - out of 
disk space for a write.  The file remains open in this case, but the 
write fails.

However, I'm thinking purely of sockets, since this code is written for 
network IO.

>> 4. return value == ERROR_SUCCESS and lpOverlapped != NULL and
>> *lpNumberOfBytes == 0
>>     - the handle we've come back on is actually a socket, and the remote
>> host has closed
> 
> The handle could be other things, but ok... 

Well, depends what you mean.  The handle can indeed be a range of 
things, but case 4 is *specifically* for sockets, as I understand the 
documentation.

>> In other words, I don't think it's possible to differentiate between
>> case 3 and 4, because in case 3, *lpNumberOfBytes might be 0 just by 
>> chance.
> 
> If you're talking about socket IO, don't worry - the iocp won't bother you
> in the case that nothing arrived or was sent,

My concern is this; in case 3, we have a general error of some sort with 
the socket.  Say a read fails but the socket remains open.

In case 4, the socket has been closed by the remote host.

The two cases are differentiated by the fact that in case 4, 
*lpNumberOfBytes == 0.

Now - here's the rub - what's to prevent *lpNumberOfBytes being 0 in 
case 3?  the docs say in case 3, the value in *lpNumberOfBytes is not 
set by GetQueuedCompletionStatus().  So, it would retain whatever value 
I set it to originally.  I'm thinking then that I need to set 
*lpNumberOfBytes to a value, say 1, and then if it's different, I'll be 
able to *know* it was set to 0.