[ python-Bugs-1025525 ] asyncore.file_dispatcher should not take fd as argument

SourceForge.net noreply at sourceforge.net
Sat Jan 6 23:06:13 CET 2007


Bugs item #1025525, was opened at 2004-09-09 22:14
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025525&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: david houlder (dhoulder)
>Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore.file_dispatcher should not take fd as argument

Initial Comment:
Only relevant to posix.
asyncore.file_dispatcher closes the file descriptor
behind the file object, and not the file object itself.
When another file gets opened, it gets the next
available fd, which on posix, is the one just released
by the close.

Tested on python 2.2.3 on RedHat Enterprise Linux 3 and
python 2.2.1 on HP Tru64 unix. See attached script for
details and a solution. 'case 1' should show the
problem regardless of the garbage collection strategy
in python. 'case 2' relies on the file object being
closed as soon as the last reference to it disappears,
which seems to be the (current?) behaviour.

[djh900 at dh djh900]$ python file_dispatcher_bug.py
case 1:
 (Read 'I am the first pipe\n' from pipe)
 (pipe closing. fd== 3 )
 (Read '' from pipe)
firstPipe.read() says 'I am the second pipe\n'
firstPipe.fileno()== 3
secondPipe.fileno()== 3

case 2:
 (Read 'I am the first pipe\n' from pipe)
 (pipe closing. fd== 3 )
 (Read '' from pipe)
secondPipe.fileno()== 3
dispatcher.secondPipe.read() says
Traceback (most recent call last):
  File "file_dispatcher_bug.py", line 77, in ?
    print "dispatcher.secondPipe.read() says",
repr(dispatcher.secondPipe.read())
IOError: [Errno 9] Bad file descriptor
[djh900 at dh djh900]$ 

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

Comment By: david houlder (dhoulder)
Date: 2004-11-17 18:43

Message:
Logged In: YES 
user_id=1119185

In an ideal world I'd propose replacing the guts of
file_wrapper() and file_dispatcher() by my pipe_wrapper()
and PipeDispatcher(), since the general problem of closing
the file descriptor behind the python object applies to all
python objects that are based on a file descriptor, not just
pipes.

So, yes, probably best not to call it pipe_dispatcher(). And
I guess file_dispatcher() may be in use by other peoples'
code and changing it to take a file object rather than an fd
will break that.

Maybe file_dispatcher.__init__() could be changed to take
either an integer file descriptor or a file object as it's
argument, and behave like the current file_dispatcher() when
given an fd, and like pipe_dispatcher() when given a
file-like object (i.e. any object with fileno() and close()
methods will probably be enough). I'm happy to whip up an
example if people think that's a good idea.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2004-11-07 10:23

Message:
Logged In: YES 
user_id=31392

I'm not sure whether you propose a change to asyncore or are
describing a pattern that allows you to use a pipe with it
safely.  And, looking at your code more closely, I think
pipe is confusing, because you're not talking about
os.pipe() right?


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

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


More information about the Python-bugs-list mailing list