3 ms·
Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to
by MuffinFlavored 8y ago
Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency.
Does Tokio use polling under the hood?
- steveklabnik 8y agoThere are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.
- MuffinFlavored 8y ago> But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. Is this implementation going to wrap epoll/kqueue/iocp? Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of? What are the popular choices other than Tokio?
- steveklabnik 8y agoTraits are not implementations, just interfaces. There won't be an implementation of one in std, just the interface, so that the ecosystem can interoperate. At the moment, I think Tokio is pretty great. I wish that there was more development bandwidth to help test out some cutting-edge stuff, but I think the design is sound. It really depends, Tokio is the most popular at the moment. This is because most of the new ecosystem is built around these new, unstable interfaces. Tokio currently runs on the older, not in the standard library one. It's all a bit confusing at the moment, to be honest.
- bb010g 8y agoFor the OP's microcontrollers, there's the excellent Real Time For The Masses: https://japaric.github.io/cortex-m-rtfm/book/en/ https://japaric.github.io/cortex-m-rtfm/book/en/