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

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Wed Jul 22 16:01:22 EDT 2009


User benoit at zeroc.com added comment

--- Comment #12 from Benoit Foucher <benoit at zeroc.com>  2009-07-22 14:01:20 MDT ---
Created an attachment (id=306994)
 --> (http://bugzilla.novell.com/attachment.cgi?id=306994)
use kqueue on OS X

I found this after a bit of research:
https://issues.apache.org/bugzilla/show_bug.cgi?id=34332, poll() on OS X seems
to be broken and even unsupported by Apple: 


I don't think it's a good idea to keep using it for OS X so I'm re-opening this
bug ;-). I also don't think it would be a good idea to advise to use blocking
sockets instead since this isn't very intuitive and this could lead to hard to
diagnose problems.

Anyway, this time I've attached a patch that includes yours and changes to the
threadpool to use kqueue on OS X instead of poll.

Since kqueue is very similar to epoll, I've mostly replaced the epoll system
calls with kevent calls. You'll notice that the pipe is still needed for
kqeuue... The reason is that it's not possible to interrupt the blocking kevent
by just closing the kqueue FD. Instead, the code closes the write end of the
pipe which wakes up the blocking kevent and the thread then closes the read
side of the pipe.

The tests of our software which make extensive use of .NET sockets pass with
this patch (w/ mono from SVN).

Note that your patch was still necessary. Without it, our tests fails with
spurious EWOULDBLOCK errors in EndReceive. I didn't investigate further but I
believe it can be expected to get sporadic EWOULDBLOCK from read/write even if
kevent/select/etc did report that the socket was ready so it's best if the
thread pool still handles this case. In theory, if the poll primitive isn't
bogus (like poll() is on OS X), this should cause a busy loop.

I only tried this patch on OS X.

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

More information about the mono-bugs mailing list