close method for ConnectedTransport

[Jonathan Lange]

bzrlib would be way more useful if ConnectedTransport and its subclasses had a disconnect() or close() method that severed the connection.

[Robert Collins (lifeless)]

Jono, can you expand on why this would make bzrlib easier to use -
transports as a whole work on a stateless-handle-to-a-directory model.
ConnectedTransport is a subclass that makes making transports which
can use a single backing tcp-or-other connection easier to write.
Other transports may have one (or more) external connections, and
ConnectedTransports might have no open connections, given the
open-as-needed model.

-Rob

[Jonathan Lange (jml)]

We use transports a lot in testing in Launchpad (I feel like I've filed this bug before, anyway...). For some of these tests, we actually require a genuine TCP disconnect. In one case, there's even application logic that's triggered by a disconnect.

I understand the transport model. Even so, we've wanted a disconnect() or close() method for over three years now. In the meantime, we've written our own crappy versions that break whenever transport implementation details change.

[Martin Pool (mbp)]

I think it's reasonable to want; I'm not sure if it should be on
Transport as such or whether we should expose a higher Connection
that's common across several of them.

[Robert Collins (lifeless)]

What makes your implementations crappy [what do we need to know, to
avoid doing, to have non-crappy ones]?

[Jonathan Lange (jml)]

On Thu, May 20, 2010 at 10:02 AM, Robert Collins
<email address hidden> wrote:
> What makes your implementations crappy [what do we need to know, to
> avoid doing, to have non-crappy ones]?
>

They are external to the transport object, but access _protected
attributes of the transport object.

[Robert Collins (lifeless)]

Ok, so nothing like 'can't get connections to stay closed' or 'a
closed transport should not be usable again' ?

[Jonathan Lange (jml)]

On Thu, May 20, 2010 at 10:39 AM, Robert Collins
<email address hidden> wrote:
> Ok, so nothing like 'can't get connections to stay closed' or 'a
> closed transport should not be usable again' ?

Nope. From our POV, we just use them for testing, and one transport
almost always == one connection.

jml

[Vincent Ladeuil (vila)]

disconnect() has been implemented while fixing thread/socket leaks.