Add the following lines to test_handle_expt (this makes sense, a
dispatcher instance is supposed to implement handle_read and call recv
in order to detect that the remote end has closed the socket):

--- a/Lib/test/test_asyncore.py
+++ b/Lib/test/test_asyncore.py
@@ -677,6 +677,9 @@
             def handle_expt(self):
                 self.flag = True
 
+            def handle_read(self):
+                self.recv(1)
+
         class TestHandler(BaseTestHandler):
             def __init__(self, conn):
                 BaseTestHandler.__init__(self, conn)

With these lines added, the test now fails on linux with Python 3.3,
see the following backtrace: select (an poll) returns a read event and
an exceptional condition for the socket, but there is no normal data
to read, only out-of-band data.

The attached patch fixes the problem.


======================================================================
ERROR: test_handle_expt (test.test_asyncore.TestAPI_UseIPv4Poll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 690, in test_handle_expt
    self.loop_waiting_for_flag(client)
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 523, in loop_waiting_for_flag
    asyncore.loop(timeout=0.01, count=1, use_poll=self.use_poll)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 215, in loop
    poll_fun(timeout, map)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 196, in poll2
    readwrite(obj, flags)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 117, in readwrite
    obj.handle_error()
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 108, in readwrite
    obj.handle_read_event()
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 439, in handle_read_event
    self.handle_read()
  File "/path_to/src/cpython/cpython-hg-default/Lib/test/test_asyncore.py", line 681, in handle_read
    self.recv(1)
  File "/path_to/src/cpython/cpython-hg-default/Lib/asyncore.py", line 379, in recv
    data = self.socket.recv(buffer_size)
BlockingIOError: [Errno 11] Resource temporarily unavailable

Hello Xavier,

> select (an poll) returns a read event and an exceptional condition 
> for the socket, but there is no normal data to read, only out-of-band
> data.

That's against POSIX:
"""
POLLIN
Data other than high-priority data may be read without blocking. For STREAMS, this flag is set in revents even if the message is of zero length. 
"""

And indeed, that's a known kernel regression introduced in 2.6.28, and fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b634f87522dff87712df8bda2a6c9061954d552a
http://kerneltrap.org/mailarchive/linux-netdev/2010/3/15/6271951

Note that there might still be a problem with the current code:
recv() can return EAGAIN on a FD reported readable/writable by select() (for example if the network stack received an input packet and then discards it because of an invalid checksum, or because the output socket buffer has room left but not enough to accomodate the packet we're trying to send): I'll have to think a bit to see if we can do something about this, but that's another issue.
Closing as invalid.

Hi Charles-François,

> And indeed, that's a known kernel regression introduced in 2.6.28,
> and fixed by this commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b634f87522dff87712df8bda2a6c9061954d552a
> http://kerneltrap.org/mailarchive/linux-netdev/2010/3/15/6271951

The BlockingIOError exception occurs on linux 2.6.30 for me.


> Note that there might still be a problem with the current code:
> recv() can return EAGAIN on a FD reported readable/writable by
> select() (for example if the network stack received an input packet
> and then discards it because of an invalid checksum, or because the
> output socket buffer has room left but not enough to accomodate the
> packet we're trying to send): I'll have to think a bit to see if we
> can do something about this, but that's another issue.

It is not clear why recv() can return EAGAIN because we're trying to
_send_ a packet ;-)


> Closing as invalid

Ok, 2.6.30 is an old kernel and urgent data is mostly never used.

> It is not clear why recv() can return EAGAIN because we're trying to
> _send_ a packet ;-)

Well, I was refering to a problem with the current implementation, not
limited to this specific example.

>> Closing as invalid
>
> Ok, 2.6.30 is an old kernel and urgent data is mostly never used.

I'll update test_asyncore to actually call recv(MSG_OOB), it's
probably a good idea to check that (hopefuly it won't break on OS
X...).