| Previous | Next |
| ETXTBSY | ESHUTDOWN |
EWOULDBLOCK
EWOULDBLOCK is a flow-control signal for a nonblocking operation. It is not a transport failure and it does not mean the work is lost. The caller must wait for the API's readiness or completion condition before attempting the operation again.
On native Windows socket APIs, the corresponding result is WSAEWOULDBLOCK, obtained through WSAGetLastError(). The UCRT's POSIX-supplement value is numerically different. This distinction matters when code mixes a cross-platform abstraction with direct Winsock calls: interpreting one numeric namespace as the other produces incorrect logs and retry logic.
Correct nonblocking behavior
- For receive, wait for readable readiness or an overlapped completion; do not poll
recvin a busy loop. - For stream send, retain the unsent suffix and resume only when the socket becomes writable or the operation completes.
- For a nonblocking connect, treat the result as pending and query the final error after the connection event.
- Apply queue bounds and backpressure so that “would block” does not turn into unbounded application buffering.
References
Looking for a different code? Search another status or error code.