Failed DisconnectEx/AcceptEx still schedules an overlapped IOCP event

Question

Windows 8, x64.

Using overlapped Windows sockets Api with IOCP.

Noticed an unexpected behavior with sockets: For example, a call to DisconnectEx returns an error WSAENOTCONN but later I receive an event in GetQueuedCompletionStatusEx for exactly this disconnect (like it was still scheduled regardless of returned error). Same happens with AcceptEx (with different error returned, e.g. WSAEINVAL).

I was expecting the IOCP event to be scheduled only for pending operations (returned error code WSA_IO_PENDING), but not other errors.

EDIT: My question is: can IOCP events be scheduled by the system even if calls to DisconnectEx/AcceptEx return an error (WSAGetLastError) that is not WSA_IO_PENDING?

Thank you!

Answer 1

The answer for the above question is no. The problem I had is I messed up scheduling several IOCP events on the same overlapped structure which resulted in this strange behavior.

Answer 2

IOCPs tend to flood you with statuses at seemingly odd times, including after you thought the handle was closed... The solution I used for this was to do a PostQueuedCompletionStatus() with a custom OVERLAPPED parameter to indicate "closed for real now" after I had closed the handle. Then any queued system statuses would be processed, and when I got the custom OVERLAPPED I knew I could free all my internal buffers related to the handle.