On 04/10/2012 7:00 AM, Robin Eidissen wrote:
Wouldn't this be fairly lightweight and fast when directly transferring control,
and a bit slow when going through channels, and via the scheduler?
Our goal is to make that sort of pattern affordable with the
abstractions we have. Two things to note about those:
1. Our "scheduler" is _really_ blunt. It picks the next runnable
task at (pseudo) random. It may well be that it has a fast(er)
path for picking a receiving task when switching-away from a
sending task on a shared pipe -- if not this is probably an
optimization worth making -- but in a scheduler with only
two tasks anyway, you can expect a pretty direct switch.
(and you're allowed to make your own sub-schedulers and confine
your tasks to them, so they will just switch back and forth)
2. The "channel" abstraction got replaced / augmented this summer
with a higher-speed and more flexible abstraction called pipes;
these are 1:1, default-synchronous and support bi-directional
communication; they'll support the scenario you describe much
more efficiently than a pair of ports and channels.
In general I expect a fair quantity of stuff we were doing with channels
to switch over to lower-level pipe protocols at some point. But this is
something that'll happen in stages; there's a lot still being-digested
from the summer (interns!)
I'm assuming the data structures required for a task are extremely lightweight,
since coroutines should be.
They're pretty lightweight. Not "nothing" -- there's a certain balance
between minimum stack chunk size and early costs of stack growth, so
wager a few kb of initial allocation -- but yes, cheap enough to spawn
many thousands of them on a normal system.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
