Gregory P. Smith <[EMAIL PROTECTED]> added the comment: The whole socket._io_refs thing looks like a real design flaw. What is its actual intended purpose?
When close is called on the socket object itself, the socket MSUT be closed. Why is our API otherwise? Its up to the programming to ensure that no other references to that socket wrapped in whatever layers will be used after that, if they are they'll eventually get errors when an IO occurs. I think this behavior started with this change: ------------------------------------------------------------------------ r56714 | jeremy.hylton | 2007-08-03 13:40:09 -0700 (Fri, 03 Aug 2007) | 21 lines Make sure socket.close() doesn't interfere with socket.makefile(). If a makefile()-generated object is open and its parent socket is closed, the parent socket should remain open until the child is closed, too. The code to support this is moderately complex and requires one extra slots in the socket object. This change fixes httplib so that several urllib2net test cases pass again. Add SocketCloser class to socket.py, which encapsulates the refcounting logic for sockets after makefile() has been called. Move SocketIO class from io module to socket module. It's only use is to implement the raw I/O methods on top of a socket to support makefile(). Add unittests to test_socket to cover various patterns of close and makefile. ............... later modified by this (still the same effect): ............... ------------------------------------------------------------------------ r58970 | guido.van.rossum | 2007-11-14 14:32:02 -0800 (Wed, 14 Nov 2007) | 6 lines Patch 1439 by Bill Janssen. I think this will work. Tested on Windows by Christian Heimes. I changed the code slightly, renaming decref_socketios() to _decref_socketios(), and moving it closer to the close() method that it calls. Hopefully Bill can now submit his SSL port to 3.0. ---------- nosy: +gvanrossum, jhylton _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3826> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
