whirlwind

I don't think I'd recommend using this in production. The benchmarks look good, but by immediately waking the waker[0], you've effectively created a spin-lock. They may work in some very specific circumstances, but they will most likely in practice be more costly to your scheduler (which likely uses locks btw) than just using locks [0]: https://github.com/fortress-build/whirlwind/blob/0e4ae5a2aba...

Benchmarks will always look good when using a spin-lock like you seem to be using here https://github.com/fortress-build/whirlwind/blob/0e4ae5a2aba...

They're just using tokio as a dev dependency. You could use this with any async runtime https://github.com/fortress-build/whirlwind/blob/main/Cargo....

When all the examples are marked with `#[tokio::main]`, it probably requires tokio. Although I guess they do implement Future on their own so it shouldn't need a specific runtime then. https://github.com/fortress-build/whirlwind/blob/main/src/sh...

Hey HN, this is Will and David from Fortress (https://news.ycombinator.com/item?id=41426998). We use a lot of async Rust internally, and created this library out of a need for an async-aware concurrent hashmap since there weren’t many available in the Rust ecosystem. Whirlwind is a sharded HashMap with a fully asynchronous API. Just as dashmap is a replacement for std::sync::RwLock<HashMap>, whirlwind aims to be a replacement for tokio::sync::RwLock<HashMap>. It has a similar design and performance characteristics to dashmap, but seems to perform better in read-heavy workloads with tokio's green threading. Benchmarks are in the readme! We used an asyncified version of dashmap's benchmark suite. The project is in a pretty early stage and I'm sure there are flaws, but I'm pretty happy with the performance. There is some unsafe involved, but