By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,172 Members | 727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,172 IT Pros & Developers. It's quick & easy.

Closing socket file descriptors

P: n/a
Hi, I'm experiencing a problem when trying to close the file descriptor
for a socket, creating another socket, and then closing the file
descriptor for that second socket. I can't tell if my issue is about
Python or POSIX.

In the following, the first time through, everything works. On the
second connection, though, the same file descriptor as the first
connection may be re-used, but for some reason, trying to do
os.read/close on that file descriptor will cause an error.

Thanks in advance for any help on why this problem is occurring and/or
how to resolve it (preferrably, I can continue to use file descriptors
instead of resorting to socket.recv/socket.close).

def handle( s ):
print id(s), s
print os.read( s.fileno(), 4096 ) # s.recv(4096)
os.close( s.fileno() ) # s.close()
svr = socket.socket()
svr.bind( ( 'localhost', 8003 ) )
svr.listen( 1 )
while True:
print 'accepting'
s,_ = svr.accept()
handle( s )

# Traceback (most recent call last):
# File "./normal_server_close_error.py", line 25, in <module>
# handle( s )
# File "./normal_server_close_error.py", line 13, in handle
# print os.read( s.fileno(), 4096 ) # s.recv(4096)
# OSError: [Errno 9] Bad file descriptor
May 20 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
js
Hello, Yang.

You're not supposed to use os.open there.
See the doc at http://docs.python.org/lib/os-fd-ops.html

Is there any reason you want to use os.close?

On 20 May 2007 04:26:12 GMT, Yang
<DE*****************@mailnulldeletethis.comwrote :
Hi, I'm experiencing a problem when trying to close the file descriptor
for a socket, creating another socket, and then closing the file
descriptor for that second socket. I can't tell if my issue is about
Python or POSIX.

In the following, the first time through, everything works. On the
second connection, though, the same file descriptor as the first
connection may be re-used, but for some reason, trying to do
os.read/close on that file descriptor will cause an error.

Thanks in advance for any help on why this problem is occurring and/or
how to resolve it (preferrably, I can continue to use file descriptors
instead of resorting to socket.recv/socket.close).

def handle( s ):
print id(s), s
print os.read( s.fileno(), 4096 ) # s.recv(4096)
os.close( s.fileno() ) # s.close()
svr = socket.socket()
svr.bind( ( 'localhost', 8003 ) )
svr.listen( 1 )
while True:
print 'accepting'
s,_ = svr.accept()
handle( s )

# Traceback (most recent call last):
# File "./normal_server_close_error.py", line 25, in <module>
# handle( s )
# File "./normal_server_close_error.py", line 13, in handle
# print os.read( s.fileno(), 4096 ) # s.recv(4096)
# OSError: [Errno 9] Bad file descriptor
--
http://mail.python.org/mailman/listinfo/python-list
May 20 '07 #2

P: n/a
Hi, thanks for your answer. Should I just use that object's close()
method? Is it safe to assume that objects that have fileno() also have
close()? (Statically typed interfaces would come in handy now.)

I'm writing a simple asynchronous I/O framework (for learning purposes -
I'm aware of the myriad such frameworks for Python), and I'm writing a
wrapper around objects that can be passed into select.select(). Since
select() requires objects that have fileno's, that's the only
requirement I place on the wrapped object's interface, and thus why I've
been using FD-based operations:

class handle( object ):
'''handle( underlying_file ) -handle object

A wrapper for a nonblocking file descriptor/handle. Wraps any object
with a fileno() method.'''

__slots__ = [ '_real' ]
# _real is the underlying file handle. Must support fileno().

def __init__( self, real_handle ):
self._real = real_handle

def fileno( self ):
return self._real.fileno()

def close( self ):
close( self._real.fileno() )
# seems that this must now become: self._real.close()

def wait_readable( self ):
...

"js " <eb*****@gmail.comwrote in
news:ma***************************************@pyt hon.org:
Hello, Yang.

You're not supposed to use os.open there.
See the doc at http://docs.python.org/lib/os-fd-ops.html

Is there any reason you want to use os.close?

On 20 May 2007 04:26:12 GMT, Yang
<DE*****************@mailnulldeletethis.comwrote :
>Hi, I'm experiencing a problem when trying to close the file
descriptor
>for a socket, creating another socket, and then closing the file
descriptor for that second socket. I can't tell if my issue is about
Python or POSIX.

In the following, the first time through, everything works. On the
second connection, though, the same file descriptor as the first
connection may be re-used, but for some reason, trying to do
os.read/close on that file descriptor will cause an error.

Thanks in advance for any help on why this problem is occurring
and/or
>how to resolve it (preferrably, I can continue to use file
descriptors
>instead of resorting to socket.recv/socket.close).

def handle( s ):
print id(s), s
print os.read( s.fileno(), 4096 ) # s.recv(4096)
os.close( s.fileno() ) # s.close()
svr = socket.socket()
svr.bind( ( 'localhost', 8003 ) )
svr.listen( 1 )
while True:
print 'accepting'
s,_ = svr.accept()
handle( s )

# Traceback (most recent call last):
# File "./normal_server_close_error.py", line 25, in <module>
# handle( s )
# File "./normal_server_close_error.py", line 13, in handle
# print os.read( s.fileno(), 4096 ) # s.recv(4096)
# OSError: [Errno 9] Bad file descriptor
--
http://mail.python.org/mailman/listinfo/python-list
May 20 '07 #3

P: n/a
js
Hi Yang.
Hi, thanks for your answer. Should I just use that object's close()
method? Is it safe to assume that objects that have fileno() also have
close()? (Statically typed interfaces would come in handy now.)
I'm writing a simple asynchronous I/O framework (for learning purposes -
I'm aware of the myriad such frameworks for Python), and I'm writing a
wrapper around objects that can be passed into select.select(). Since
select() requires objects that have fileno's, that's the only
requirement I place on the wrapped object's interface, and thus why I've
been using FD-based operations:
I'm not sure whether objects which have fileno always have close,
but I think it's always safe to use the object's close method.
How about keeping the wrapped object's interface consistent
in your framework?
It'd make your work moch easier.
May 20 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.