6 ms·

> Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively made on the ground of "we want to ship async support a

by comex 6y ago

> Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively made on the ground of "we want to ship async support as soon as possible" [1]. That is not an accurate summary of that comment. withoutboats may have been complaining about someone trying to revisit the decision made in 2015-2016, but as the comment itself points out, there were good reasons for that decision. Mainly two reasons, as far as I know. First, Rust prefers unique ownership and acyclic data structures. You can make cyclic structures work if you use RefCell and Rc and Weak, but you're giving up the static guarantees that the borrow checker gives you in favor of a bunch of dynamic checks for 'is this in use' and 'is this still alive', which are easy to get wrong. But a completion-based model essentially requires a cyclic data structure: a parent future creates a child future (and can then cancel it), which then calls back to the parent future when it's complete. You might be able to minimize cyclicity by having the child own the parent and treating cancellation as a special case, but then you lose uniqueness if one parent has multiple children. (Actually, even the polling model has a bit of cyclicity with Wakers, but it's kept to an absolute minimum.) Second, a completion-based model makes it hard to avoid giving each future its own dynamic allocation, whereas Rust likes to minimize dynamic allocations. (It also requires indirect calls, which is a micro-inefficiency, although I'm not convinced that matters very much; current Rust futures have some significant micro-inefficiencies of their own.) The 2016 blog post linked in the comment goes into more detail about this. As you might guess, I find those reasons compelling, and I think a polling-based model would still be the right choice even if Rust's async model was being redesigned from scratch today. Edit: Though to be fair, the YouTube video linked from withoutboats' comment does mention that mio decided on polling simply because that's what worked best on Linux at the time (pre-io_uring), and that had some influence on how Futures ended up. But only some. …That said, I do agree Pin was rushed and has serious problems.

newpavlov 6y ago
>That is not an accurate summary of that comment. How is to so, if he explicitly writes: > Suggestions that we should revisit our underlying futures model are suggestions that we should revert back to the state we were in 3 or 4 years ago, and start over from that point. <..> Trying to provide answers to these questions would be off-topic for this thread; the point is that answering them, and proving the answers correct, is work. What amounts to a solid decade of labor-years between the different contributors so far would have to be redone again. How should I read it except like "we did the work on the poll-based model, so we don't want for the results to go down the drain in the case if the completion-based model will turn to be superior"? I don't agree with your assertion regarding cyclic structures and the need of dynamic allocations in the completion-based model. Both models result in approximately the same cyclisity of task states, no wonders, since task states are effectively size-bound stacks. In both models you have more or less the same finite state machines. The only difference is in how those FSMs interact with runtime and in the fact that in the completion-based model you usually pass ownership of a task state part to runtime during task suspension. So you can not simply drop a task if you no longer need its results, you have to explicitly request its cancellation from runtime.
- comex 6y ago
  > How is to so, if he explicitly writes: There's a difference between "we decided this 3 years ago" and "we rushed the decision". At this point, it's no longer possible to weigh the two models on a neutral scale, because changing the model would cause a huge amount of ecosystem churn. But that doesn't mean they weren't properly weighed in the first place. Regarding cyclicity… well, consider something like a task running two sub-tasks at the same time. That works out quite naturally in a polling-based model, but in a completion-based model you have to worry about things like 'what if both completion handlers are called at the same time', or even 'what if one of the completion handlers ends up calling the other one'. Regarding dynamic allocations… well, what kind of desugaring are you thinking of? If you have async fn foo(input: u32) -> String; then a simple desugaring could be fn foo(input: u32, completion: Arc<FnOnce(String)>); but then the function has to responsible for allocating its own memory. Sure, there are alternatives. We could do... struct Foo { /* state */ } impl Foo { fn call(self: Arc<Self>, input: u32, completion: Arc<FnOnce(String)>); } Which by itself is no better; it still implies separate allocations. But then I suppose we could have an `ArcDerived<T>` which acts like `Arc<T>` but can point to a part of a larger allocation, so that `self` and `completion` could be parts of the same object. However, in that case, how do you deal with borrowed arguments? You could rewrite them to Arc, I suppose. But if you must use Arc, performance-wise, ideally you want to be moving references around rather than actually bumping reference counts. You can usually do that if there's just `self` and `completion`, but not if there are a bunch of other Arcs. Also, what if the implementation misbehaved and called `completion` without giving up the reference to `self`? That would imply that any further async calls by the caller could not use the same memory. It's possible to work around this, but I think it would start to make the interface relatively ugly, less ergonomic to implement manually. Also, `ArcDerived` would have to consist of two pointers and there would have to be at least one `ArcDerived` in every nested future, bloating the future object. But really you don't want to mandate one particular implementation of Arc, so you need a vtable, but that means indirect calls and more space waste. Most of those problems could be solved by making the interface unsafe and using something with more complex correctness requirements than Arc. But the fact that current async fns desugar to a safe interface is a significant upside. (...Even if the safety must be provided with a bunch of macros, thanks to Pin not being built into the language.)
yxhuvud 6y ago
> First, Rust prefers unique ownership and acyclic data structures. You can make cyclic structures work if you use RefCell and Rc and Weak, but you're giving up the static guarantees that the borrow checker gives you in favor of a bunch of dynamic checks for 'is this in use' and 'is this still alive', One way to get around that is to instead of doing it like the very structureless async way actually impose lifetime restrictions on the lifetimes of async entities. For example, if you use the ideas of the structured concurrency movement ([x], for example but it has since been picked up by kotlin, swift and other projects), then the parent is guaranteed to live longer than any child thus solving most of the problem that way. [x] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
- mratsim 6y ago
  The structured parallelism movement predates structured concurrency by years and needs a similar push. It's from 2004 with the X10 parallel language and then Habanero in Java via their "async-finish" construct I wonder if your quote (structured XYZ or ABC considered harmful) is inspired by - https://conf.researchr.org/details/etaps-2019/places-2019-papers/2/Keynote-Unstructured-Parallelism-Considered-Harmful-Using-Structured-Parallelism- https://conf.researchr.org/details/etaps-2019/places-2019-pa...
  - yxhuvud 6y ago
    Well the link I posted is older than your link from 2019 so I doubt that. The other direction may be possible. However, enither are definitely not the first having ideas along these lines - structures and logic like this can also be found in Erlang supervisors after all. And as for the quote, it is quite explicitly referring to Dijkstra and structured programming constructs in nonconcurrent settings.
    - mratsim 6y ago
      X10 Programming language is from 2004, http://x10-lang.org/x10-community/publications-using-x10.html http://x10-lang.org/x10-community/publications-using-x10.htm... Habanero Java from 2011 https://www.cs.rice.edu/~vs3/PDF/hj-pppj11.pdf https://www.cs.rice.edu/~vs3/PDF/hj-pppj11.pdf

by comex 6y ago

newpavlov 6y ago

>That is not an accurate summary of that comment. How is to so, if he explicitly writes: > Suggestions that we should revisit our underlying futures model are suggestions that we should revert back to the state we were in 3 or 4 years ago, and start over from that point. <..> Trying to provide answers to these questions would be off-topic for this thread; the point is that answering them, and proving the answers correct, is work. What amounts to a solid decade of labor-years between the different contributors so far would have to be redone again. How should I read it except like "we did the work on the poll-based model, so we don't want for the results to go down the drain in the case if the completion-based model will turn to be superior"? I don't agree with your assertion regarding cyclic structures and the need of dynamic allocations in the completion-based model. Both models result in approximately the same cyclisity of task states, no wonders, since task states are effectively size-bound stacks. In both models you have more or less the same finite state machines. The only difference is in how those FSMs interact with runtime and in the fact that in the completion-based model you usually pass ownership of a task state part to runtime during task suspension. So you can not simply drop a task if you no longer need its results, you have to explicitly request its cancellation from runtime.

comex 6y ago
> How is to so, if he explicitly writes: There's a difference between "we decided this 3 years ago" and "we rushed the decision". At this point, it's no longer possible to weigh the two models on a neutral scale, because changing the model would cause a huge amount of ecosystem churn. But that doesn't mean they weren't properly weighed in the first place. Regarding cyclicity… well, consider something like a task running two sub-tasks at the same time. That works out quite naturally in a polling-based model, but in a completion-based model you have to worry about things like 'what if both completion handlers are called at the same time', or even 'what if one of the completion handlers ends up calling the other one'. Regarding dynamic allocations… well, what kind of desugaring are you thinking of? If you have async fn foo(input: u32) -> String; then a simple desugaring could be fn foo(input: u32, completion: Arc<FnOnce(String)>); but then the function has to responsible for allocating its own memory. Sure, there are alternatives. We could do... struct Foo { /* state */ } impl Foo { fn call(self: Arc<Self>, input: u32, completion: Arc<FnOnce(String)>); } Which by itself is no better; it still implies separate allocations. But then I suppose we could have an `ArcDerived<T>` which acts like `Arc<T>` but can point to a part of a larger allocation, so that `self` and `completion` could be parts of the same object. However, in that case, how do you deal with borrowed arguments? You could rewrite them to Arc, I suppose. But if you must use Arc, performance-wise, ideally you want to be moving references around rather than actually bumping reference counts. You can usually do that if there's just `self` and `completion`, but not if there are a bunch of other Arcs. Also, what if the implementation misbehaved and called `completion` without giving up the reference to `self`? That would imply that any further async calls by the caller could not use the same memory. It's possible to work around this, but I think it would start to make the interface relatively ugly, less ergonomic to implement manually. Also, `ArcDerived` would have to consist of two pointers and there would have to be at least one `ArcDerived` in every nested future, bloating the future object. But really you don't want to mandate one particular implementation of Arc, so you need a vtable, but that means indirect calls and more space waste. Most of those problems could be solved by making the interface unsafe and using something with more complex correctness requirements than Arc. But the fact that current async fns desugar to a safe interface is a significant upside. (...Even if the safety must be provided with a bunch of macros, thanks to Pin not being built into the language.)

yxhuvud 6y ago

> First, Rust prefers unique ownership and acyclic data structures. You can make cyclic structures work if you use RefCell and Rc and Weak, but you're giving up the static guarantees that the borrow checker gives you in favor of a bunch of dynamic checks for 'is this in use' and 'is this still alive', One way to get around that is to instead of doing it like the very structureless async way actually impose lifetime restrictions on the lifetimes of async entities. For example, if you use the ideas of the structured concurrency movement ([x], for example but it has since been picked up by kotlin, swift and other projects), then the parent is guaranteed to live longer than any child thus solving most of the problem that way. [x] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

mratsim 6y ago
The structured parallelism movement predates structured concurrency by years and needs a similar push. It's from 2004 with the X10 parallel language and then Habanero in Java via their "async-finish" construct I wonder if your quote (structured XYZ or ABC considered harmful) is inspired by - https://conf.researchr.org/details/etaps-2019/places-2019-papers/2/Keynote-Unstructured-Parallelism-Considered-Harmful-Using-Structured-Parallelism- https://conf.researchr.org/details/etaps-2019/places-2019-pa...
- yxhuvud 6y ago
  Well the link I posted is older than your link from 2019 so I doubt that. The other direction may be possible. However, enither are definitely not the first having ideas along these lines - structures and logic like this can also be found in Erlang supervisors after all. And as for the quote, it is quite explicitly referring to Dijkstra and structured programming constructs in nonconcurrent settings.
  - mratsim 6y ago
    X10 Programming language is from 2004, http://x10-lang.org/x10-community/publications-using-x10.html http://x10-lang.org/x10-community/publications-using-x10.htm... Habanero Java from 2011 https://www.cs.rice.edu/~vs3/PDF/hj-pppj11.pdf https://www.cs.rice.edu/~vs3/PDF/hj-pppj11.pdf