| msg171967 - (view) |
Author: (Nidan) |
Date: 2012-10-04 16:06 |
| I recently had lots of the following exception: error: uncaptured python exception, closing channel <servercore_persistent.ConnectionHandler connected 127.0.0.1:53609 at 0x8d27eec> (<class 'socket.error'>:[Errno 11] Resource temporarily unavailable [/usr/lib/python2.7/asynchat.py|handle_read |
110] [/usr/lib/python2.7/asyncore.py |
recv |
| msg187846 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) *  |
Date: 2013-04-26 13:09 |
| I confirm I can reproduce this issue also in pyftpdlib: https://code.google.com/p/pyftpdlib/issues/detail?id=255 Current proposed patch returning '' is not ideal as for asynchat '' is an alias for 'connection lost'. In summary recv() in case of EAGAIN should return None and asynchat.handle_read() should take that into account. Will provide a patch later. |
|
|
| msg187848 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2013-04-26 13:37 |
| Patch is in attachment. I'm a bit worried about Python versions < 3.4 because this kinds of breaks backward compatibility as recv() is not expected to return None but I see no other saner solution. |
|
|
| msg188206 - (view) |
Author: (Nidan) |
Date: 2013-05-01 10:54 |
| 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. |
|
|
| msg188248 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2013-05-02 00:30 |
| recv() returning an empty string has always been an alias for "connection lost" though, that is why it cannot be used and I was proposing returning a new type in Python 3.4. Point is we're paying a bad design decision: asyncore shouldn't have asked the user to call recv() directly in the first place and call a data_received(chunk) callback method instead. Deciding what's best to do at this point without breaking existent code is not easy, that is why I think that on python <= 3.3 we should fix *asynchat* in order to take EAGAIN/EWOULDBLOCK into account and leave asyncore's recv() alone. The issue would still exist but it would be mitigated by the fact that who wants to write a protocol is likely to use asynchat, not asyncore. As for Python 3.4 we can: - make asyncore's recv() return None and document it - deprecate recv() - introduce data_received(chunk) |
|
|
| msg188817 - (view) |
Author: Xavier de Gaye (xdegaye) *  |
Date: 2013-05-10 08:35 |
| For the reson why read() must still check for EWOULDBLOCK even though after select() has reported a file descriptor ready for reading, see the BUGS section of select linux man page, which says: Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block. |
|
|
| msg188821 - (view) |
Author: Xavier de Gaye (xdegaye) * |
Date: 2013-05-10 09:22 |
| > Deciding what's best to do at this point without breaking existent > code is not easy, that is why I think that on python <= 3.3 we > should fix *asynchat* in order to take EAGAIN/EWOULDBLOCK into > account and leave asyncore's recv() alone. IMHO for all python versions, asynchat should be fixed and recv() left unchanged raising OSError with EAGAIN/EWOULDBLOCK. With the proposed change on recv(), asyncore users would need to handle this new None returned value anyway, instead of handling the exception which is much more explicit. The attached patch does this on the default branch. |
|
|
| msg220629 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2014-06-15 12:53 |
| Could we have a review of the latest path from Xavier please. Aside, "add Windows project file for _sha3 module. I choose to build _sha3 as a sparat module as it's rather large (190k for AMD64).", presumably Christian mistyped an issue number? |
|
|
| msg221728 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2014-06-27 20:55 |
| EWOULDBLOCK.patch: asyncio ignores BlockingIOError on sock.recv(), "except BlockingIOError:" is more portable and future proof than "_RETRY = frozenset((EWOULDBLOCK, EAGAIN))". Except of that, EWOULDBLOCK.patch change looks correct. |
|
|
| msg221732 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2014-06-27 21:01 |
| Modifying recv() to return None doesn't look correct. I read it as: "you should always use recv() output, except if the result is None: in this case, do nothing". In Python, we use exceptions for that. BUT in fact, sock.recv() already raises an exception, so asyncore should not convert the exception to a magic value (None). Modifying the behaviour of recv() in asyncore breaks the backward compatibility. Returning None makes it harder to write asyncore code working on Python 3.4 and 3.5 (if the change is done in Python 3.5). I prefer EWOULDBLOCK.patch approach: document the issue in asyncore documentation and handle BlockingIOError in asynchat. |
|
|
| msg221733 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2014-06-27 21:04 |
| See also the issue #15982 which is the exactly the same on Windows. (By the way, the asyncore module has been marked as deprecated in Python 3.4 in favor of asyncio, and this issue is already solved in asyncio.) |
|
|
| msg223859 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2014-07-24 17:00 |
| New changeset b7f144d14798 by Victor Stinner in branch '3.4': Issue #16133: The asynchat.async_chat.handle_read() method now ignores http://hg.python.org/cpython/rev/b7f144d14798 New changeset aa150c7a5d24 by Victor Stinner in branch 'default': (Merge 3.4) Issue #16133: The asynchat.async_chat.handle_read() method now http://hg.python.org/cpython/rev/aa150c7a5d24 |
|
|
| msg223861 - (view) |
Author: Roundup Robot (python-dev) |
Date: 2014-07-24 17:15 |
| New changeset d422062d7d36 by Victor Stinner in branch '2.7': Issue #16133: The asynchat.async_chat.handle_read() method now ignores http://hg.python.org/cpython/rev/d422062d7d36 |
|
|
| msg223862 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2014-07-24 17:17 |
| I modified EWOULDBLOCK.patch to use BlockingIOError on Python 3 and I added a unit test. I also added EALREADY and EINPROGRESS which are used by the BlockingIOError in Python 3, just in case. Thanks Xavier for your patch, sorry for the delay. |
|
|