[Mono-bugs] [Bug 470120] Socket.EndSend unexpectedly fails with WSAEWOULDBLOCK

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Tue Jul 21 17:46:11 EDT 2009


User benoit at zeroc.com added comment

Benoit Foucher <benoit at zeroc.com> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #8 from Benoit Foucher <benoit at zeroc.com>  2009-07-21 15:46:11 MDT ---
It's not clear to me why you're closing this bug. EWOULDBLOCK is an expected
error condition for non-blocking sockets whether or not you check readiness
with select or poll.

And throwing this exception seems wrong to me even if the socket is set to
non-blocking.  We don't have this problem with .NET and it would be really
annoying if we had to use a blocking socket to get BeginSend/EndSend to behave
properly (we use a mix of BeginSend/EndSend and non-blocking Send to send

I don't know well the implementation of the mono thread pool, but this bug
seems to indicate that it doesn't handle EWOULDBLOCK when calling send on a
socket (and possibly recv?). Does it instead rely on blocking send/recv,
eventually causing (possibly many) threads to block on socket IO?

If that's the case it seems to me that it would be better if it did handle
EWOULDBLOCK as this an expected condition for a non-blocking socket if the send
buffer fills up or if there's not enough data in the receive buffer (regardless
of whether or not you use select()/poll() to get readiness information on the
socket). It could also relinquish the thread pool thread upon getting this
error condition and wait for the socket to be ready again.

Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

More information about the mono-bugs mailing list