[ python-Bugs-539444 ] asyncore file wrapper & os.error

[SourceForge.net]

Bugs item #539444, was opened at 2002-04-04 12:57
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore file wrapper & os.error

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-07 13:35

Message:
Logged In: YES 
user_id=341410
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-01-07 11:18

Message:
Logged In: YES 
user_id=21627
Originator: NO

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?

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-07 10:03

Message:
Logged In: YES 
user_id=341410
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2007-01-07 02:45

Message:
Logged In: YES 
user_id=21627
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-06 22:00

Message:
Logged In: YES 
user_id=341410
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-07 01:03

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

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 08:44

Message:
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 


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-05 01:00

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470