[New-bugs-announce] [issue15523] Block on close TCP socket in SocketServer.py
report at bugs.python.org
Wed Aug 1 12:07:48 CEST 2012
New submission from Jarvis:
In the Python 2.4, it closes the socket only by calling request.close() method. There is a risk by using this method to close socket. If the socket handle count does not reach zero because another process still has a handle to the socket then the connection is not closed and the socket is not deallocated. So in Python 2.7 it updates it by calling request.shutdown() first, which can close the underlying connection and send a FIN/EOF to the peer regardless of how many processes have handles to the socket. After that, it calls request.close() to deallocate the socket. You can see this updates below that is from the file of C:\Python27\Lib\SocketServer.py.
def shutdown_request(self, request):
"""Called to shutdown and close an individual request."""
#explicitly shutdown. socket.close() merely releases
#the socket and waits for GC to perform the actual close.
pass #some platforms may raise ENOTCONN here
However,it will block at self.close_request(request) after request.shutdown(socket.SHUT_WR) if there are remaining data on reading side of socket.
Here, it calls request.shutdown() with SHUT_WR flag, which means it only shuts down the writing side of the socket. The reading side of the socket isn't shut down at same time. So when calling close_request to deallocate the socket, it will always be waiting to read response until response data is available. It seems like an issue in SokcetServer.py library.
In terms of that, I replaced the SHUT_WR flag with SHUT_RDWR (shut down both reading and writing sides of the socket) for request.shutdown method. Then this issue was resolved, the SSL connection was closed immediately.
title: Block on close TCP socket in SocketServer.py
versions: Python 2.7
Python tracker <report at bugs.python.org>
More information about the New-bugs-announce