It's up to you how to treat an error condition, but the question is a sign of potential problems in your code (from logic errors to undefined behavior).
The most important point is that you shouldn't touch SOCKET handle after closesocket
. What do you do on EOF? It would be logical to closesocket
on our side when we detect EOF, but that's what you cannot do in ERROR_NETNAME_DELETED
handler, because closesocket
already happened and the handle is invalid.
It's also profitable to imagine what happens if pending read completes (with real data available) just before closesocket
, and your application detects it right after closesocket
. You handle incoming data and... Do you send an answer to the client using the same socket handle? Do you schedule the next read on that handle? It would be all wrong, and there would be no ERROR_NETNAME_DELETED
to tell you about it.
What happens if pending read completes with EOF in that very unfortunate moment, just before closesocket
? If your regular OnEof
callback is fired, and that callback does closesocket
, it would be wrong again.
The problem you describe might hint at more serious problem if closesocket
is done in one thread, while another thread waits for I/O completion. Are you sure that another thread is not calling WSARecv
/ReadFile
while the first thread is calling closesocket
? That's undefined behavior, even though winsock makes it look as if it worked most of the time.
To summarize, the code handling completing (or failing) reads cannot be correct if it's unaware of socket handle being useless because it was closed. After closesocket
, it's useful to wait for pending I/O completion because you can't reuse OVERLAPPED
structure if you don't; but there's no point in handling this kind of completion as if it happened during normal operation, with socket being still open (error/status code is irrelevant).