| 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 |
| 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. |
|
|