[Python-3000] socket GC worries

[Bill Janssen]

> 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