This could be achieved by using a persistent data structure based on
ARC. The tricky part is to write one generic shared data that can be
used with both @ (single-task) and ARC (cross-task). This can probably
be achieved, but it'll require some thought and maybe some bugfixes in
the trait code. :)
Niko
Lucian Branescu wrote:
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]
<mailto:[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
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] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
