[Python-3000] socket GC worries
Guido van Rossum
guido at python.org
Mon Oct 29 21:32:14 CET 2007
2007/10/29, Bill Janssen <janssen at parc.com>:
> > 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.
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.
> Hmmm, does real_close even get called in that case? In the C module,
The C module will certainly close the fd when the object goes away.
The question is, is that soon enough.
> > 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.
I'll look into this later.
> And, ref your other comments, why not call SocketIO "TCPStream"? It
> would make things much clearer.
Good idea; SocketIO made more sense when it was part of io.py.
> 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.
Really? AFAIK everyone who opens a socket calls it.
I'd be okay with calling the class Socket and having a factory
function named socket though.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000