On Wed, Nov 13, 2013 at 10:49 AM, Bill Myers <bill_my...@outlook.com> wrote:
> I see several proposals for the future of Rust tasks, and I think one of > the best approaches is being overlooked, and that is something similar to > async in C# (http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx > ). > > In C#, the "async" keyword can be applied to functions and it causes the > compiler to transform a function that returns T into a function that > returns a Task<T> (which is C#'s name for a future of type T) representing > the potentially asynchronous computation. > > Blocking is representing by using the "await" keyword on a future > (typically returned by a call to another "async" function), and it causes > the compiler to perform a Continuation-Passing Style transformation, and > attach the continuation to the future, returning another future > representing the composed computation. > > I/O functions are designed to return futures, so in this system blocking > causes all calling "async" functions to return, building up a chain of > continuations on the heap, which is equivalent to the machine stack in a > current-Rust task, but which is as small as needed, and is only used for > call chains that block. > > In Rust, this transformation is much more delicate, because the resulting > return value futures must have a lifetime that is the smallest among all > the arguments to the function, if those arguments are needed by the > continuation, and the argument types must be "shareable" between parallel > forks (e.g. std::rc::Rc is not shareable because RC manipulation is > non-atomic). > Can you please elaborate on this point? What arguments are you talking about here, and why future's lifetime needs to be restricted?
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
