3 ms·
You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generato
by yoshuaw 2mo ago
You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions:
https://blog.yoshuawuyts.com/gen-auto-trait-problem https://blog.yoshuawuyts.com/gen-auto-trait-problem
- stymaar 2mo agoThanks for the explanation (though I have to admit I liked your old blog theme more). Since it's just a matter of how async get desugared, can it be changed through an edition?
- Dagonfly 2mo agoOh yeah, I've read about all your blog post on this topic :) To dump some ideas on you: I think one missing piece might be that FnOnce() -> impl Future should implement IntoFuture. Async runtimes would then use IntoFuture in their APIs agressively. I call this a "workload blueprint" at work. Its a closure/type that contains all the info to start the workload, but in a minimal form. In Rust terms this would be a buildprint that is ideally Send + Move + Forget + 'static, even if the actual work (and the backing struct of the Future) is !Send (e.g. It holds an Rc across await points). Runtimes could use this for their advantage: There would be a global pool of "workload blueprint" that can be stolen by any executer thread, but once a !Send workload has started on one thread it can't be migrated to another. This in combination with matklad's ideas about seperating TaskSend from ThreadSend (https://matklad.github.io/2023/12/10/nsfw.html https://matklad.github.io/2023/12/10/nsfw.html) would solve most of my async pain points.