classification
Title: asyncore file wrapper & os.error
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: josiahcarlson Nosy List: brett.cannon, jhylton, josiahcarlson, loewis
Priority: normal Keywords:

Created on 2002-04-04 20:57 by jhylton, last changed 2007-09-13 23:41 by brett.cannon. This issue is now closed.

Messages (11)
msg10164 - (view) Author: Jeremy Hylton (jhylton) (Python triager) 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) * (Python committer) 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) (Python triager) 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) * (Python committer) 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) * (Python triager) 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) * (Python committer) 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) * (Python triager) 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) * (Python committer) 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) * (Python triager) 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) * (Python committer) 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) * (Python committer) 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
2007-09-13 23:41:39brett.cannonsetstatus: open -> closed
nosy: + brett.cannon
resolution: not a bug
messages: + msg55901
2002-04-04 20:57:26jhyltoncreate