On 02/20/2013 06:38 PM, 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
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 ?
If you are ok with serialization (and want to implement it for `List`)
then `std::flatpipes` should be able to send `List`.
Without resorting to reflection, one thing we could possibly do is allow
the current task to swap its heap with another, then just call the
standard `.clone()` method, cloning into the new heap. At that point you
could put that heap into another task. With some care such a thing could
possibly by wrapped up into a safe interface, but it's kind of a scary
notion to be swapping heaps.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
