[issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK

2012-10-04 Thread Nidan

New submission from Nidan:

I recently had lots of the following exception:
error: uncaptured python exception, closing channel 
 (:[Errno 11] Resource temporarily unavailable 
[/usr/lib/python2.7/asynchat.py|handle_read|110] 
[/usr/lib/python2.7/asyncore.py|recv|384])

Error 11 is EAGAIN or EWOULDBLOCK, so asyncore/asynchat tries to read from a 
nonblocking socket which has no data available. Since this is a temporary error 
the socket shouldn't be closed.

The bug can be fixed by changing asyncore.dispatcher.recv to
def recv(self, buffer_size):
try:
data = self.socket.recv(buffer_size)
if not data:
# a closed connection is indicated by signaling
# a read condition, and having recv() return 0.
self.handle_close()
return ''
else:
return data
except socket.error, why:
# winsock sometimes throws ENOTCONN
if why.args[0] in _DISCONNECTED:
self.handle_close()
return ''
elif why.args[0] in (EAGAIN, EWOULDBLOCK):
return ''
else:
raise

While looking at the source I also saw that asyncore.dispatcher.send and 
.connect check against EWOULDBLOCK but not against EAGAIN. Since both constants 
may have different values and POSIX allows to return either of them these 
functions should check against both error constants.

--
components: Library (Lib)
messages: 171967
nosy: Nidan
priority: normal
severity: normal
status: open
title: asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker 
<http://bugs.python.org/issue16133>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK

2013-05-01 Thread Nidan

Nidan added the comment:

Why should asynchat.handle_read care about closed sockets if asyncore.recv does 
that already?
Currently asynchat.handle_read handles empty strings from asycore.recv 
gracefully (by doing some unnecessary work aka executing the remainder of the 
function), it doesn't treat them specially. The only path that might cause 
asynchat.handle_read to close the socket requires asycore.recv to throw.
Introducing None as possible return value from asyncore.recv therefore seems 
unnecessary to me.

Changed the patch accordingly.

--
Added file: http://bugs.python.org/file30088/issue16133.patch

___
Python tracker 
<http://bugs.python.org/issue16133>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com