I don't have any concrete solutions to offer, just a few scattered thoughts:
- In our recent discussions at the all-hands, we were leaning towards
eliminating the ability to send higher-order data over channels. This would be
in tension with the desire to migrate tasks.
- Migrating tasks could be simulated in a lightweight way (for example, I
believe you could implement GCD on top of something like the existing task
model) if we could send closures over channels: the dispatcher would send work
as functions to tasks.
- Migrating tasks could be done in a more expressive way if we had
continuations: you could suspend your entire task. (This may just be an
equivalent way of looking at task migration. But actually continuations can be
a good fit for lower-level languages like Rust, independent of the use case of
migration: they are helpful for building systems like OSes and web servers. I'm
not advocating, just putting this out there.)
- I don't have insight into how to deal efficiently with the heap when you
migrate tasks. But FWIW the following paper has some nice description of
different implementation strategies for some of the other parts of the puzzle
(particularly growable and storable stacks):
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70.9076
Don't know how much of that is useful/relevant but I've always liked the paper
so I figured I'd mention it.
Dave
On Apr 15, 2011, at 8:32 AM, Marijn Haverbeke wrote:
>> They have pointers into a heap shared with other tasks in their thread. We'd
>> have to dig through that heap cloning everything they point to.
>
> Right. I can see the costs, but you have to agree that migrating tasks
> would be a *great* thing to have. Having shared values become more
> complicated might be worth it. Unique boxes are one good solution. You
> also alluded to a task-lifetime trick last week (task X holding onto
> immutable value Z, and not being allowed to die until task Y, which
> accesses this value, finishes -- if I understood it correctly). There
> are probably other hacks that can be applied when sharing big
> structures. For small ones, copying is a good idea anyway.
>
> Of course, this'd also upset our current design of domains and such.
> I'm not really putting myself behind any new approach at this point,
> but I think we should definitely be open to anything that would help
> us avoid costly and awkward I/O multiplexing magic.
> _______________________________________________
> 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
