crossbeam VS tokio

That's it. Everything else — async/await, actors, work-stealing executors, lock-free data structures — lives in the ecosystem (tokio, rayon, crossbeam, actix, etc.).

One very common queue implementation you can use to implement actors is the crossbeam-deque. It's work-stealing in nature, works in multi-threaded environments and has no locks. The implementation is quite simple to follow:

https://github.com/crossbeam-rs/crossbeam/blob/master/crossb...

Sure! However, the work-stealing queue in rayon [1] uses three atomic operations instead of the two atomic operations for a mutex for a global lock. The difference, however, is the three atomic operations for the thread-local queue should be uncontended, whereas a global lock on a global work queue would experience contention from every thread trying to access it for jobs.

Between the choices of "single work sharing queue with a big mutex on it that all threads access for work" vs "per-thread work-stealing queue that's uncontended for the cost of one extra atomic," in what situations would the work-sharing queue with the global mutex outperform? Perhaps if there's a small number of jobs, and there's not enough time for the work-stealing algorithm to distribute jobs to the worker threads before the work-sharing algorithm has already finished.

[1]: https://github.com/crossbeam-rs/crossbeam/blob/423e46fe20471...

Crossbeam isn't async[0]. It can multiplex with itself (via the `select!` macro), but not with anything else.

[0]: https://github.com/crossbeam-rs/crossbeam/issues/896

Shooting from the hip, crossbeam might be a good candidate for understanding the thread safety aspects of Rust. I kind of feel like this is probably "too big" of a project if you're just learning, but I can't think of something smaller off the top of my head that would be suitable.

I am familiar with crossbeam channels, but now I need to work with python, and I was looking for a similar library.

In the C++ example you create a naive mpsc queue using a std queue and a mutex, while in the rust example you use `std::sync::mpsc` which is now implemented internally using https://github.com/crossbeam-rs/crossbeam .

There are more in the ecosystem like in https://crates.io/crates/crossbeam

The crossbeam crate offers a powerful alternative to standard channels with support for the Select operation, timeouts, and more.

That's it. Everything else — async/await, actors, work-stealing executors, lock-free data structures — lives in the ecosystem (tokio, rayon, crossbeam, actix, etc.).

Building LlamaStash brought me back to a lot of that, but the ground has shifted. ratatui (the maintained fork of tui-rs) is a real, polished framework now. tokio makes async daemons boring in a good way. hyper gives you a respectable HTTP server in a few hundred lines. crossterm handles the cross-platform terminal mess. sysinfo covers host metrics. The pieces are all there and you have LLMs to help you speed up everything to 10x.

The async ecosystem has matured to the point where this is actually enjoyable to build now. Tokio is the async runtime most production Rust services are built on, and Axum gives you an ergonomic HTTP layer that won’t make you miss Go’s simplicity quite as much as you’d expect.

Tokio — Async runtime para Rust — Runtime más usado para servicios de red y concurrencia en Rust.

Understanding the internals won't change how you write async Rust day to day, but it changes how you think about it. That mental model helps when you find you're on one of Rust's sharp edges. If you want to go deeper, the tokio source, this blog post by Priyanka Yadav, and Jon Gjengset's async Rust series are the best next steps.

In fastjson-api, I leveraged Rust’s async capabilities with tokio to handle thousands of simultaneous connections efficiently. The project demonstrates how Rust’s zero-cost abstractions can lead to a lightweight, high-throughput API server.

https://github.com/tokio-rs/tokio/pull/7622

The tests do not appear to simulate the queue in Loom, which would be a very, very good idea.

This stuff is _hard_, and I almost certainly made a mistake in the above. In practice, the queue is probably fine to use, but I wouldn't be shocked if there's a heisenbug lurking in this codebase that manifests something like: it all works fine now, but in the next LLVM version an optimization pass which breaks it on ARM, and after that the queue yield duplicate values in a busy loop every few million reads which is only triggered in release mode on Graviton processors.

Or something. Like I said, this stuff is _hard_. I wrote a very detailed simulator for the Rust/C++ memory model, have implemented dozens of lockless algorithms, and I still make a mistake every time I go to write code. You need to simulate it with something like Loom to have any hope of a robust implementation.

For anyone interested in learning about Rust's memory model, I can't recommend enough Rust Atomics and Locks:

https://marabos.nl/atomics/

Asynchronous Processing: With the power of tokio, the server handles DNS queries asynchronously, with no blocking, improving scalability and latency.

It's definitely a bit contrived, but to me it's also emblematic of the issues with async Rust.

The note on mpsc::Sender::send losing the message on drop [1] was actually added by me [2], after I wrote the Oxide RFD on cancellations [3] that this talk is a distilled form of. So even the great folks on the Tokio project hadn't considered this particular landmine.

[1] https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.h...

[2] https://github.com/tokio-rs/tokio/pull/5947

[3] https://rfd.shared.oxide.computer/rfd/0400

Asynchronous programming has seen considerable adoption, and Rust's Tokio runtime provides an excellent framework for writing asynchronous code. Utilizing async/await syntax in Rust allows for efficient concurrent execution in I/O-bound applications.