A related problem is using a persistent data structure and a swap to allow several tasks to operate on the same immutable data structure and change the top-level reference atomically, basically transactions.
Clojure operates this way and it works quite well, but I don't see how it would work in rust without copies. On 21 February 2013 14:21, Niko Matsakis <[email protected]> wrote: > The problem with allocating memory in another task is that it's kind of a > "rendezvous" operation, since you must pause both tasks so that neither > performs a GC etc during the time of the copy. Personally I think we > should stick with serialization unless it becomes a true burden. We'll > probably have to improve the serializer to handle cyclic data structures at > some point though. > > If there is a true performance problem, we could build an API that allowed > you to allocate arbitrary data structures in an arena that can then be sent > to other tasks as a unit. In this way one could send an arbitrary graph in > constant time. This takes a little bit of thought and care and maybe > require some minor extensions to the type system. > > > Niko > > Ashish Myles wrote: > >> I didn't much previous discussion on this topic on google. Sorry if I >> missed something and re-starting an old discussion. >> >> Here is an example from the manual of a standard lisp-style list. >> enum List<T> { >> Nil, >> Cons(T, @List<T>) >> } >> If one wished to move such a list to another task, a copy to unique >> pointers would be needed. But it seems that this data structure doesn't >> support any way of unique-ifying it, it would have to be copied to >> a transferable data structure (like ~[T]) >> and reconstructed on the other side. As converting to another container >> might not be as optimal for, say a tree or more complex data type, is >> there another way to deal with such a use-case? >> I see a serialization/de-serialization approach was suggested here: >> https://github.com/mozilla/**rust/issues/3836<https://github.com/mozilla/rust/issues/3836> >> Perhaps, a viable alternative would be to have a cloning procedure (given >> two tasks specified) that creates managed memory only on the receiving >> side while cloning? Something like a "copy to that task's heap and send >> it a pointer" functionality ? >> >> Ashish >> >> ______________________________**_________________ >> Rust-dev mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >> > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
