As I understand it Rust tasks seem a lot like coroutines, but can't quite be used like one.
What I'd like is to be able to create a task B from my task A, and then directly transfer control from A to B by calling for example "coro::resume" on it, until it "yields" a value (not task::yield, maybe coro::yield), which will return control (and the value) directly back to A. Calling task::yield from B would return control to the scheduler (which does not know about B), and when it later resumes A, control starts after the task::yield in B. Now it seems like you'd have to spawn a task to run in the scheduler, pass it a channel to which it writes the values, and which we can later read from. I'd like to do (maybe stupid) things like writing a parser as a coroutine, to which I pass a single character at a time, and it then yields either NeedMore or Value(x) for example. It is an extremely attractive way of writing certain kinds of code. Wouldn't this be fairly lightweight and fast when directly transferring control, and a bit slow when going through channels, and via the scheduler? Would it be possible for tasks to serve this dual-purpose, able to both be run in the scheduler, and also able to be directly invoked from other tasks? Is it already possible, or maybe it would be a bad way of implementing coroutines? I'm assuming the data structures required for a task are extremely lightweight, since coroutines should be. - Robin _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
