Lifetime on Channel, Sftp

[beamspease]

The explicit lifetime needed on Channel and Sftp creates a lot of problems.

First, I asked about creating a struct that holds the socket, the session, and the channels and was told that there isn't any good way to do self-referencing structs in #rust-beginners.

Second, it becomes viral and infects additional traits and generics, leading to errors such as E0207.
rust-lang/rust#25041

From my reading, it sounds like the recommended solution is Rc or similar.

This one design decision is making it look like the project I'm working on may be infeasible to do in Rust. I'm refactoring code to try and dodge the issue, but it's a real pain.

[alexcrichton]

Yeah the API here is kinda unfortunate but it reflects what libssh2 is doing under the hood. (it internally isn't using reference counting).

It should be safe, however, to throw a Session into an Rc, transmute its lifetime to 'static, and then pair the Rc with a Channel or other sub-resource. That way the sub-resource has the 'static lifetime and persists a reference to the Session with it.

[beamspease]

Thanks. I hammered on it all night and, with some help from a few people in #rust-beginners, was able to get past the blockage by adding another lifetime.

I worked around not being able to set the fields on the struct simultaneously by making the channels optional and setting them after the effect. It adds a bit of boilerplate but nothing too terrible.

I haven't used transmute yet, but that sounds like it may be a more elegant solution.

[alexcrichton]

Yeah working around this definitely isn't trivial, but I'm thinking of something like:

struct OwnedChannel {
    inner: Channel<'static>,
    _session: Rc<Session>,
}

(or along those lines at least)

[beamspease]

How I've worked around this so far is by creating a connector struct that exists concurrently with the struct that represents the actual connection. There's a connect() function that creates and returns the channels created from the SSH session and stores them in the object representing the connection handle.

I'm still not terribly happy with it since what I've read suggests that the Connection should take ownership of the handle. I did try the approach you suggested, but I got bogged down in some aspect of it that I can't remember now. However I tackled this in the first few weeks of learning Rust, on what turned out to be the most lifetime-complex part of what I've written so far, so the results might be different if I took a stab at it.

My solution and some other cases of storing child objects derived from some parent object has guided me towards feeling that self-referential structs are important to allow a container object to take ownership of a source object when it's also storing derived objects. Short of the approach above (which would incur overhead, albeit very slight, which could become more significant in large numbers of transient objects) or unsafe{} I'm not sure how you would implement something like that using lifetimes. Supposedly there are crates, but it's a counter-intuitive situation to need a third-party library for that. Though I digress a bit.

[alexcrichton]

Yeah unfortunately I think a perfect solution here isn't great (we may not have enough language features), but I think we can nonetheless still improve the status quo! If I were to redo the API I think I'd do away with all the borrows. Especially as an async-capable library I think working with borrows is just too onerous and not worth it in the long run.

If you're interested in upstreaming that I'd be ok releasing a new major version as well!

[beamspease]

At this point I've gotten comfortable enough with lifetimes that it hasn't been a major stumbling block, but I might revise that in the context of futurizing things.

…

On Tuesday, April 18, 2017, Alex Crichton ***@***.***> wrote: Yeah unfortunately I think a perfect solution here isn't great (we may not have enough language features), but I think we can nonetheless still improve the status quo! If I were to redo the API I think I'd do away with all the borrows. Especially as an async-capable library I think working with borrows is just too onerous and not worth it in the long run. If you're interested in upstreaming that I'd be ok releasing a new major version as well! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMDN2-iapLNuw3osbmb6QFPJF98v9jJoks5rxXFngaJpZM4LyTup> .

-- - Steven

[wez]

I've made some changes to this on master that remove the borrows; these will be in the next release of ssh2