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*?
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
