[Python-3000] socket GC worries

[Guido van Rossum]

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,
> perhaps?

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/)