[Python-3000] socket GC worries
Bill Janssen
janssen at parc.com
Tue Oct 30 18:37:29 CET 2007
> > 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
More information about the Python-3000
mailing list