Leave ownership model to library users

[milibopp]

Hey, there. Toyed around a little with this library. Great job!

I would very much like to use this for carboxyl, my Rust FRP library. The issue addressing this (aepsil0n/carboxyl#14) has been open for a long time.

Anyway, one immediate thought that struck me, when I browsed your code, was, that there is an awful lot of Arcs and static lifetimes in there. This is a good way to get started, as lifetime issues can be hairy. But it also pretty much sets the memory management model of library users in stone. It reminded me of my first steps with carboxyl, when I had layers of pointer indirection stacked on top of each other.

However, in my experience it is often possible to get rid of this. As a potential benefit users can freely choose different memory management strategies for their Vars. Theoretically, it should also allow better performance due to a tighter memory layout.

I'm going to explore this idea a bit further to see if it works. So far I took the liberty to scratch at the surface by making your STM monad lifetime-generic (see #2). This was mainly because I found it odd to clone a Var every time I wanted to use it in different transactions.

Perhaps you have considered or looked into this already? I would be very glad about your thoughts on what kind of issues you would anticipate or whether there are strong reasons against it.

[milibopp]

Turns out lifetime issues are indeed hairy. It seems also like this would require making the log explicit, as it can't be a thread-local variable, when its lifetime is limited by the vars it manipulates.

What are your thoughts on that? My impression is that it makes the API slightly more complex. The question is whether that complexity is worth the flexibility in terms of memory management.

[Marthog]

Hi and thanks for the pull request.

I don't want to make the interface more complex for the normal library users, but I would like to have some more extensibility for the experts. Right now I can't estimate how much the interface would change by an explicit log. Could you show an example, how you think it will look like?

I don't like the many Arcs as well, but for many cases I either needed the ability to safely share them across theads or I needed type erasure.

[milibopp]

It is well possible that the majority of use cases for this simply cannot deal with the ownership semantics at compile-time. So consider this an experiment for now. I tried to go into a similar direction before and figured it was way to complex. I can push my attempts, so you can have a look, but I did not get to a point that I find acceptable yet.

But the basic idea looks like this:

let var = Var::new(0);
let stm = stm!(log, {
    let x = var.read(log);
    var.write(log, x + 4);
});

Effectively every read and write has to specify the log it interacts with, but the API guarantees that there can only be one log per thread at a time. However, this log does have different types as it needs a lifetime that fits its scope. In this context, the value of a Var would be allocated on the stack.

I have found a solution for the lifetime issues I encountered, but it is somewhat hacky and causes trouble when trying to reproduce the old semantics within the same code base. So I was looking into a better way of abstracting the static versus scoped lifetimes away, which is where the current code structure bit me. Therefore I decided to do some refactoring on top of the current master before going any further. I also have to understand the underlying internals better to figure out what is possible.

Anyway, let me push my code…

[milibopp]

There is a pull request for the refactor steps now, see #4.

And perhaps you want to check out my work in progress branch concerning the non-static lifetimes using an explicit log here.

[jnicholls]

Aww, sad this thread died off :)

[milibopp]

I got distracted and started doing other things ;)