[Libevent-users] GetQueuedCompletionStatus return values question/problem

[Toby Douglass]

Gordon Scott wrote:
>>> 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.

> Not true.  As per the documentation in condition 3 sets the number of bytes
> read.  If there is an error and 0 bytes have been read, it will be set 
> to 0.

Thankyou - I had been thinking this in the past, but so many different 
things have been said in the list I'd lost sight of it!

> Setting a value of 1 would lead to problems for the same reason, what if 1
> byte was read?  -1 could be an option

It's a DWORD, so -1 is a theoretically valid value, although it's fine 
in practical terms.  But I'm looking for a better way - which basically 
means treating case 3 and 4 as the same and either not differentiating 
between them, or using GLE to differentiate.

> Really though, the difference between case 3 and 4 is that GetLastError()
> returns an error code in case 3, and it does not return an error code in
> case 4

You mean to say that it returns ERROR_SUCCESS in case 4 but never will 
in case 3?  is ERROR_SUCCESS what you get from say recv() when the other 
end has done a graceful close?  I'm thinking that the GLE you get is 
actually the GLE set by the socket operation.  Also, the problem again 
is that the possible GLE codes are *not* documented.  We may assert we 
*believe* we'll get ERROR_SUCCESS in case 4 and never in case 3, but how 
can we *know*?