> > 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
Guido van Rossum python.org> writes:
>
> 2007/10/29, Greg Ewing canterbury.ac.nz>:
> > 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 th
> 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 wo
> > 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).
> > Wait
2007/10/30, Bill Janssen <[EMAIL PROTECTED]>:
> Indeed. The httplib code is relying on the fact that close(), under
> certain circumstances, has no effect. It's just that the
> circumstances have changed, in Python 3K. I think that the close() in
> HTTPConnection should be removed.
I'd like to
> Bill Janssen wrote:
>
> > Back to your initial mail (which is
> > more relevant than Greg Ewing's snipe!):
Actually, Bill Janssen didn't write that, but did write this:
> > then in some
> > cases *closes* the socket (thereby reasonably rendering the socket
> > *dead*), *then* returns the "file
Guido van Rossum wrote:
> having read()
> and write() methods on the _socket object is not the solution.
It's not a necessary part of the solution, I agree.
I just don't see what purpose is served by requiring
an extra layer of wrapper between a socket and the
other I/O layers. That's not a necess
2007/10/29, Greg Ewing <[EMAIL PROTECTED]>:
> Guido van Rossum wrote:
>
> > That's because I don't find the synonyms a good idea.
>
> Even if it means that stream sockets then have the
> same interface as all other stream-like objects in
> the I/O system, so buffering layers can be used on
> them,
Guido van Rossum wrote:
> That's because I don't find the synonyms a good idea.
Even if it means that stream sockets then have the
same interface as all other stream-like objects in
the I/O system, so buffering layers can be used on
them, etc.? That seems like a rather good reason to
me.
If you
2007/10/29, Greg Ewing <[EMAIL PROTECTED]>:
> 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
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.
> Really? AFAIK everyone who opens a socket calls it.
Sorry, I meant only a handful (10?) in the standard library.
> I'd be okay with calling the class Socket and having a factory
> function named socket though.
Ah, good idea.
Bill
___
Python-3000 mai
2007/10/29, Bill Janssen <[EMAIL PROTECTED]>:
> > Actually, I'm still up for tweaks to the I/O model if it solves a real
> > problem, as long as most of the high-level APIs stay the same (there
> > simply is too much code that expects those to behave a certain way).
> >
> > I don't quite understand
2007/10/29, Bill Janssen <[EMAIL PROTECTED]>:
> > 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 calle
> Actually, I'm still up for tweaks to the I/O model if it solves a real
> problem, as long as most of the high-level APIs stay the same (there
> simply is too much code that expects those to behave a certain way).
>
> I don't quite understand what you mean by inverted though.
I'm actually thinkin
> 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 g
2007/10/28, Bill Janssen <[EMAIL PROTECTED]>:
> > Bill Janssen wrote:
> > > that whole mess of code is a good argument for *not* exposing the
> > > fileno in Python
> >
> > Seems to me that a socket should already *be* a file,
> > so it shouldn't need a makefile() method and you
> > shouldn't have
> Bill Janssen wrote:
> > that whole mess of code is a good argument for *not* exposing the
> > fileno in Python
>
> 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.
I like that model, too. I al
Bill Janssen wrote:
> that whole mess of code is a good argument for *not* exposing the
> fileno in Python
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.
--
Greg
___
I've now got a working SSL patch for Py3K (assuming that the patches
for #1347 and #1349 are committed), but I'm a bit worried about the
lazy GC of sockets. I find that simply dropping an SSLSocket on the
floor doesn't GC the C structures. This implies that the instance in
the SSLSocket._sslobj s
20 matches
Mail list logo
