What the hell is Tokio? Articles mentions it like once I was expecting some programing principles from Japan
Principles for Fast Tokio Applications
31–40 of 72 posts
Re: Principles for Fast Tokio Applications
#32"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: https://docs.rs/tokio/latest/tokio/sync/index.html ). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I…
(I am OP) Both good call outs. Will update the article to include them
Re: Principles for Fast Tokio Applications
#33Earlier quoted context omitted.
Also a great way to make sure that your app spends most of its time in observability overhead. For example even the latency histogram that the OP mentions is wildly expensive.
If you’re not using eBPF to trace your app you’re doing it wrong.
Doesn’t that only work on Linux? And then only for things that make syscalls? Presumably people have to trace other slow paths sometime.
Re: Principles for Fast Tokio Applications
#34All of the significant server applications I have encountered in the industry have suffered from the same problem, which surprised their authors but seemed obvious to me: the application was spending the majority of its CPU time doing meta-work like entering and leaving epoll, stealing work from itself, etc. There are principles for writing Tokio servers and these are good points in the OP but I think they are little…
Do you have any references for these principles for writing Tokio servers? Or just a high level summary of what best practices look like?
Re: Principles for Fast Tokio Applications
#35Earlier quoted context omitted.
The difference is nobody in the C++ community believes that a dominant asynchronous executor library exists, and there is not a pervasive belief that it would be helpful.
The "C++ community", if it even exists, barely believes in sharing code let alone any library being "dominant." They'd have to agree on a build system first, after all. But honestly that's a mischaracterization of the situation in Rust. Tokio is popular for networked service backends. If that's the wheelhouse you're in then yea it might look "dominant."
You don't need a build system to share code.
You can share with header files and respective (shared) object files regardless of the build system you're using. Likewise you could just share the source. None of this needs a build system.
Re: Principles for Fast Tokio Applications
#36[flagged]
Re: Principles for Fast Tokio Applications
#37When you're at a point of tuning Tokio, consider taking a look at ef_vi/DPDK + SPDK
I don't think there is a ton of overlap. tokio is appropriate for general userspace apps, ranging anywhere from a CLI, GUI, API or web app. DPDK and SPDK are specialized fast paths for building network data paths and storage solutions that come with tradeoffs: DPDK uses poll mode drivers, outside of the operating system, which have various implications including busy waiting and taking over the interface. That is why…
Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.
> tokio is appropriate for general userspace apps
Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.
Re: Principles for Fast Tokio Applications
#38What the hell is Tokio? Articles mentions it like once I was expecting some programing principles from Japan
https://github.com/tokio-rs/tokio
To further explain. Rust doesn't provide a runtime/framework for async/await, you have to bring your own. Tokio is (I believe) the most popular async/await framework for rust.
Re: Principles for Fast Tokio Applications
#39Earlier quoted context omitted.
One legitimately great thing about LLMs is that it makes it feasible to add these kind of tracing instrumentations temporarily for profiling and then throw them away so they never reach source control let alone production.
I can get an LLM to trace my incomprehensible Tokio application which was also written by an LLM, which is why I don't understand its behavior. Truly the future we were promised.
I guess you should adopt RFCs or ADRs to help clarify the Tokio application, like this https://github.com/brunoarueira/thoth-mesh/tree/main/docs/ad.... This project is vibe coded, but I had put the effort to create issues, roadmap and ADRs, so later I can understand the project without going deep on the code!
Re: Principles for Fast Tokio Applications
#40"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: https://docs.rs/tokio/latest/tokio/sync/index.html ). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I…
Tasks and channels is the way. You can get something that feels like programming a real preemptive concurrency model like BEAM languages or golang but with minimal overhead.