http://bugzilla.novell.com/show_bug.cgi?id=470120
User [email protected] added comment http://bugzilla.novell.com/show_bug.cgi?id=470120#c8 Benoit Foucher <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #8 from Benoit Foucher <[email protected]> 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 data...). 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
