> > 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. > > Ouch. Unfortunately adding a __del__() method that calls close() > won't really help, as the cyclic GC refuses to do anything with > objects having a __del__. This needs more thinking than I have time > for right now, but i agree we need to fix it.
But if we remove SocketCloser, there's no need for the cyclic GC to be involved. If the count (of the number of outstanding SocketIO instances pointing to this socket.socket) is just moved into the socket.socket object itself, there's no cyclic reference, and normal refcounting should work just fine. I don't even think a __del__ method on socket.socket is necessary. > > 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. > > I'll look into this later. OK. 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
