undefined | Better HN

0 pointssliken2y ago0 comments

So just ignore the async use cases? Or force tokio or similar to support it?

My biggest pain point so far is channels, I like them in go because they are straight forward to use, allow concurrency, aren't a minefield of problems, and are easy to reason with. I wanted to scan N directories (in parallel) -> encrypt and checksum in (parallel) -> queue files for upload. With go channels it's straight forward.

I was looking for MPMC (like go channels) to allow multiple producers to enqueue and multiple consumers to dequeue. Rust doesn't do it and tokio doesn't do it. I could use crossbeam[0], flume[1], or async[2]. Not sure what limitations those have and what if any limitations in compatibilities with other crates I need will be.

[0] https://docs.rs/crossbeam/latest/crossbeam/channel/index.htm...

[1] https://docs.rs/flume/latest/flume/

[2] https://docs.rs/async-channel/latest/async_channel/

0 comments

LegionMammal9782y ago

FWIW, either async-channel's types or flume's async APIs should work for your use case. Both are completely agnostic to the async runtime, since the futures are triggered by internal events (recv() waits for send() and vice versa), rather than external events like I/O which are generally coordinated through the runtime.

worik2y ago

> So just ignore the async use cases? Or force tokio or similar to support it?

Hell no!

Do it differently

aw16211072y ago

Differently how?

And perhaps more importantly, what tradeoff(s) would those differences entail?

Ygg22y ago

Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use.

Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.

2 more replies

j / k navigate · click thread line to collapse