4 ms·
withoutboats mentioned trying to get something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster into the standard library. I th
by bryanlarsen 2y ago
withoutboats mentioned trying to get something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster into the standard library. I think that's a great idea. They don't want to put an executor into the standard library because that would "pick a winner" before the ideas are settled. But pollster allows async crates to be useful to sync code, is obviously not a "winner" and its inclusion in the standard library would force crates to be properly executor-agnostic.
- zesterer 2y agoThe problem with this is that pollster doesn't, by itself, provide a signalling mechanism by which bottom-level futures (such as OS-provided IO primitives) can signal the executor. It isn't a "light-weight replacement" for tokio, tokio does a lot of stuff that pollster simply can't because tokio is a reactor + a runtime, whereas pollster is just a runtime. [This page](https://rust-lang.github.io/async-book/08_ecosystem/00_chapter.html#determining-ecosystem-compatibility https://rust-lang.github.io/async-book/08_ecosystem/00_chapt...) gives some nice details about the difference, and hopefully some sense of the sheer difficult that comes with trying to integrate a default reactor into `std` without it falling well short when it comes to extensibility.