Transport.close()

[Andrew Bennetts]

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> David Allouche wrote:
> > I think it is essential for long-lived clients to be able to explicitly
> > close a connection.
> 
> Okay.  But since multiple Transports use the same connection, what
> should the effect be on the other Transports that use the same connection?
> 
> While we don't do a lot of async, I believe that the file objects
> returned by Transport.get can be returned before the download is
> complete.  So there is the possibility of invoking Transport.close while
> an operation is in progress on the same connection.
> 
> And even so, it doesn't seem nice to disconnect other Transports that
> may have further use for the connection.
> 
> But if it just decrements a reference count, it seems a bit silly,
> because Transports are already reference-counted.

If you're referring to the reference counting CPython does already as part of
its garbage collection, it's not good enough.

There's no way to definitely disconnect a transport that you know you are done
with, because perhaps there's another reference to it somewhere by accident.

There's no way to disconnect a transport *now*, even if you are sure you can
delete all references to it, because Python-the-language does not guarantee
collection will happen at any particular time, or even at all.  (CPython will
always collect when the refcount hits 0, but Jython and IronPython for instance
do not, and this is explicitly acceptable behaviour for an implementation to
make).

If the only way to signal "I'm done with you" to a transport is to drop your
reference to it, then it's very difficult to write tests about transport
disconnection behaviour.

There are probably other issues as well.

I agree that there's no easy answer (e.g. because multiple transport objects can
share connections) but the status quo is inadequate.

-Andrew.