Yes this is what I said previously when I mentioned before that GLE will return the standard winsock error codes for any socket errors.
>>Also, the problem again is that the possible GLE codes are *not* documented.
The winsock error codes are documented. If it's another error code, do you really care?
>>We may assert we *believe* we'll get ERROR_SUCCESS in case 4 and never in case 3, but how can we *know*?
GLE is the standard error mechanism for any type of windows programming. Regardless as to what the value of the specific error actually *IS* the fact that it is set to something other than 0 indicates an error. I have NEVER seen anyone use an error code of 0 before to indicate failure, and especially not in the standard Windows API.
Regardless if GetQueuedCompletionStatus == 0 and lpOverlapped != NULL, you can't do anything else on that socket.
If GLE != 0 treat it as an error and log a message or what not
If GLE == 0 assume a normal closure.
That's the way my code works, and I've never seen a problem with it before.
_______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
