| The concept of a pseudo-thread you're referring to is a task. A task contains a whole tree of futures awaiting other futures. So no manual propagation is necessary. Of course, it's possible for tasks to spawn other tasks that execute independently. (To be clear, if you are awaiting something from within your task, it is not a separate task.) For spawning new tasks, there's a standard API[1], which doesn't include any executor-specific stuff like priority. You'll have to decide what you want the default behavior to be when someone calls this; for example, a newly spawned task can inherit the priority of its parent. To get more sophisticated, you could even have a "spawn policy" field for every task that your first-party code knows how to set. Any new task spawned from within that task inherits priority according to that task's policy. The executor implementation decides what tasks look like and how to spawn new ones, so you can go crazy. (Not that you necessarily should, that is.) To summarize the Rust approach, I'd say you have 3 main extension points: 1. The executor, which controls the spawning, prioritization, and execution of tasks 2. Custom combinators (like join_all[2]), which allow you to customize the implementation of poll[3] and, say, customize how sub-futures are prioritized (This is at the same level as await, so per-Future, not per-Task.) 3. Leaf futures (like the ones that read or write to a socket). These are responsible for working with the executor to schedule their future wake-ups (with, say, epoll or some other mechanism). For more on this, see [4]. [1]: https://doc.rust-lang.org/1.28.0/std/task/trait.Executor.htm... [2]: https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-a... [3]: https://doc.rust-lang.org/1.28.0/std/future/trait.Future.htm... [4]: https://boats.gitlab.io/blog/post/wakers-i/ |