> The SocketCloser class wasn't written with > the SSL use case in mind.
I don't think it's just SSL. The problem is that it explicitly counts calls to "close()". So if you let the GC sweep up after you, that close() just doesn't get called, the circular refs persist, and the resource doesn't get collected till the backup GC runs (if it does). Waiting for that to happen, you might run out of a scarce system resource (file descriptors). A nasty timing-dependent bug, there. Hmmm, does real_close even get called in that case? In the C module, perhaps? > If you wanted to reuse the _socket after closing > the SSL instance, you'd have to wrap it in a fresh socket instance. > > Does that make sense? (Please do note the difference throughout > between _socket and socket, the former being defined in socketmodule.c > and the latter in socket.py.) That's what I do with SSLSocket, pretty much. I worry that doing it with socket.socket might break a lot of non-TCP code, though. And perhaps it's overkill. Why not move the count of how many SocketIO instances are pointing to it into the socket.socket class again, as it was in 2.x? I don't think you're gaining anything with the circular data structure of SocketCloser. Add a "_closed" property, and "__del__" method to socket.socket (which calls "close()"). Remove SocketCloser. You're finished, and there's one less class to maintain. And, ref your other comments, why not call SocketIO "TCPStream"? It would make things much clearer. Also, is it too late to rename socket.socket to "socket.Socket"? There are only a handful of references to "socket.socket" outside of the socket and ssl modules. Bill _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
