[Python-3000] socket GC worries

[Greg Ewing]

I wrote:

 > Seems to me that a socket should already *be* a file,
 > so it shouldn't need a makefile() method and you
 > shouldn't have to mess around with filenos.

Guido van Rossum wrote:

> That model fits TCP/IP streams just fine, but doesn't work so well for
> UDP and other odd socket types.

No, but I think that a socket should have read() and
write() methods that work if it happens to be a socket
of an appropriate kind. Unix lets you use read and write
as synonyms for send and recv on stream sockets, and
it's surprising that Python doesn't do the same.

At the very least, it should be possible to wrap
any of the higher-level I/O stack objects around a
stream socket directly.

> The real issue seems to be file descriptor GC. Maybe we haven't
> written down the rules clearly enough for when the fd is supposed to
> be GC'ed

I don't see what's so difficult about this. Each file
descriptor should be owned by exactly one object. If
two objects need to share a fd, then you dup() it so
that each one has its own fd. When the object is
close()d or GCed, it closes its fd.

However, I don't see that it should be necessary for
objects to share fds in the first place. Buffering
layers should wrap directly around the the object
being buffered, whether a file or socket or something
else. Then whether the socket has a fd or not is
an implementation detail of the socket object, so
there's no problem on Windows.

Bill Janssen wrote:

> Back to your initial mail (which is
> more relevant than Greg Ewing's snipe!):

What snipe? I'm trying to make a constructive suggestion.

> then in some
> cases *closes* the socket (thereby reasonably rendering the socket
> *dead*), *then* returns the "file" to the caller as part of the
> response.

I don't understand that. What good can returning a *closed* file
object possibly do anyone?

--
Greg