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
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
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
