Closing socket file descriptors

[Yang]

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_c lose_error.py", line 25, in <module>
# handle( s )
# File "./normal_server_c lose_error.py", line 13, in handle
# print os.read( s.fileno(), 4096 ) # s.recv(4096)
# OSError: [Errno 9] Bad file descriptor

[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************ *****@mailnulld eletethis.comwr ote:

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_c lose_error.py", line 25, in <module>
# handle( s )
# File "./normal_server_c lose_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

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

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.file no()

def close( self ):
close( self._real.file no() )
# seems that this must now become: self._real.clos e()

def wait_readable( self ):
...

"js " <eb*****@gmail. comwrote in
news:ma******** *************** *************** *@python.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************ *****@mailnulld eletethis.comwr ote:

>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_c lose_error.py", line 25, in <module>
# handle( s )
# File "./normal_server_c lose_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

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