On 11/3/06, Toby Douglass <[EMAIL PROTECTED]> wrote:
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?
Yes, that's what I mentioned a couple days ago.
We may assert we *believe* we'll get ERROR_SUCCESS in case 4 and never in case
3, but how can we *know*?
Per MSDN, in case 3, a failed I/O is being dequeued. MSDN says to
call GLE to see what the error is. You just have to take it on faith
GQCS works as described and GLE will give you the error code. As
Gordon mentioned, the GLE code will map to the socket error codes and
will not be 0 (ERROR_SUCCESS).
What I've done in the past, is pump a few trillion sessions thru my
IOCP code. In your error handling code (case 3) check for a reset,
handle as needed. If it's not a reset, log the error value, and
system error message (use FormatMessage). See what errors you are
getting in the real world.
I don't think you'll find that you get any causal errors that will
allow you to keep working with the socket at that point.
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
