Issue539444
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-04-04 20:57 by jhylton, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Messages (11) | |||
---|---|---|---|
msg10164 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-04-04 20:57 | |
The file wrapper makes a file descriptor look like an asycnore socket. When its recv() method is invoked, it calls os.read(). I use this in an application where os.read() occasionally raises os.error (11, 'Resource temporarily unavailable'). I think that asyncore should catch this error and treat it just like EWOULDBLOCK. But I'd like a second opinion. |
|||
msg10165 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-04-05 09:00 | |
Logged In: YES user_id=21627 Can you report details of the file that returns EWOULDBLOCK? This is not supposed to happen in applications of the file_wrapper. |
|||
msg10166 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-04-05 16:44 | |
Logged In: YES user_id=31392 It happens when the file is a pipe. For details, see the ZEO bug report at https://sourceforge.net/tracker/index.php? func=detail&aid=536416&group_id=15628&atid=115628 I've included the traceback from that bug report, too. error: uncaptured python exception, closing channel <select-trigger (pipe) at 81059cc> (exceptions.OSError:[Errno 11] Resource temporarily unavailable [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|poll|92] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|handle_read_event|386] [/home/zope/opt/Python-2.1.2/lib/python2.1/site- packages/ZEO/trigger.py|handle_read|95] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|recv|338] [/home/zope/opt/Python- 2.1.2/lib/python2.1/asyncore.py|recv|520]) Exception exceptions.OSError: (9, 'Bad file descriptor') in <method trigger.__del__ of trigger instance at 0x81059cc> ignored |
|||
msg10167 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-04-07 09:03 | |
Logged In: YES user_id=21627 I'm still uncertain what precisely was happening here. What system was this on? On many systems, EAGAIN is EWOULDBLOCK; if that is the case, adding EAGAIN to the places that currently handle EWOULDBLOCK won't change anything. |
|||
msg10168 - (view) | Author: Josiah Carlson (josiahcarlson) * | Date: 2007-01-07 06:00 | |
I don't see an issue with treating EAGAIN as EWOULDBLOCK. In the cases where EAGAIN != EWOULDBLOCK (in terms of constant value), treating them the same would be the right thing. In the case where the values were the same, nothing would change. |
|||
msg10169 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2007-01-07 10:45 | |
Notice that the ZODB issue is marked as fixed. I would like to know how that was fixed, and I still would like to know what operating system this problem occurred on. |
|||
msg10170 - (view) | Author: Josiah Carlson (josiahcarlson) * | Date: 2007-01-07 18:03 | |
Jeremy Hylton states what he did to fix it in ZEO. In terms of platform, I would guess that this is likely linux, as multiple people seem to be able to reproduce the error, and you can't reliably use signals in Windows without killing the process. |
|||
msg10171 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2007-01-07 19:18 | |
Ok; still I wonder what the problem is. In the original report, Jeremy said "should catch this error and treat it just like EWOULDBLOCK". Now, EWOULDBLOCK is handled in dispatcher.connect, dispatcher.accept, and dispatcher.send - not in dispatcher.recv. So what would it help to treat EAGAIN the same way? |
|||
msg10172 - (view) | Author: Josiah Carlson (josiahcarlson) * | Date: 2007-01-07 21:35 | |
I seem to have misread it as being for send. Presumably they would want to handle EAGAIN/EWOULDBLOCK in recv, though the semantic of returning an empty string when it was polled as being readable, is generally seen as a condition to close the socket. I'm leaning towards closing as invalid, as "fixing" the behavior would result in the semantics of recv being ambiguous. |
|||
msg10173 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2007-01-07 21:49 | |
What still puzzles me is why recv is invoked at all. According to the traceback, it was invoked because poll() indicated a read event for the pipe, yet trying to read from it failed with EAGAIN. Either there still is a bug in asyncore, or there is a bug in the operating system, or the traceback is bogus. |
|||
msg55901 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2007-09-13 23:41 | |
Following Josiah's advice and closing this as this has been sitting here long enough. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:11 | admin | set | github: 36383 |
2007-09-13 23:41:39 | brett.cannon | set | status: open -> closed nosy: + brett.cannon resolution: not a bug messages: + msg55901 |
2002-04-04 20:57:26 | jhylton | create |