Geert Jansen added the comment:
It seems that SSLSocket.close() doesn't actually close the socket, and that's
why the server side read() blocks.
It's a bit of a mystery to me how socket.close(), which is called by SSLSocket
to do the actual close, is supposed to work. I don't see any calls to
_sock.close() in there..
If I add the following 3 lines to socket.py then it works (but there's a few
unexpected EOF errors in return).
diff -r ae64614b66b7 Lib/socket.py
--- a/Lib/socket.py Sat Oct 04 18:24:32 2014 -0400
+++ b/Lib/socket.py Sun Oct 05 18:16:51 2014 -0400
@@ -192,6 +192,9 @@
def close(self, _closedsocket=_closedsocket,
_delegate_methods=_delegate_methods, setattr=setattr):
# This function should not reference any globals. See issue #808164.
+ if hasattr(self._sock, '_dummy'):
+ return
+ self._sock.close()
self._sock = _closedsocket()
dummy = self._sock._dummy
for method in _delegate_methods:
I'm probably overlooking something b/c I can't imagine socket.close() being a
no-op.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22559>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
