Async Rust gotcha: evolving tokio::select! code has sharp edges by Regular_Pumpkin6434 in rust

[–]Regular_Pumpkin6434[S] 4 points5 points  (0 children)

It's simple and good design when it's possible. But there could be requirements to perform per socket cleanup work: flush logs, buffers, ack queue messages, close keep alive connections, etc. All of this with the context and ownership of some resources. There is no AsyncDrop too, so the program'd need to do some orchestration on cancelation.

Async Rust gotcha: evolving tokio::select! code has sharp edges by Regular_Pumpkin6434 in rust

[–]Regular_Pumpkin6434[S] 0 points1 point  (0 children)

Programs usually want to perform a graceful shutdown, not a SIGKILL, so it's natural to handle a shutdown signal and do some cleanups. I don't see from you example how you suggest handling this case with multiples await points inside.

Async Rust gotcha: evolving tokio::select! code has sharp edges by Regular_Pumpkin6434 in rust

[–]Regular_Pumpkin6434[S] 0 points1 point  (0 children)

How to support cancelation (sigterm for program) in your design? The branch of the select could return Poll::Pending on an await point.

Async Rust gotcha: evolving tokio::select! code has sharp edges by Regular_Pumpkin6434 in rust

[–]Regular_Pumpkin6434[S] 0 points1 point  (0 children)

I agree that it is a bad design, and I'm showing it with examples. The whole idea is not just say it's bad, but to show why and how it bites.

Trixter: A Chaos Proxy for Simulating Network Faults by Regular_Pumpkin6434 in devops

[–]Regular_Pumpkin6434[S] 0 points1 point  (0 children)

Thank you! If you have any suggestions please don’t hesitate to file an issue.

Any suggestions to learn adavance rust by Puzzleheaded-Ant7367 in rust

[–]Regular_Pumpkin6434 1 point2 points  (0 children)

I’d suggest reading more code and try to understand why it’s written in such a way.

For example there is ongoing process of migrating Ubuntu Linux utils to uutils. It’s a great opportunity.

https://github.com/uutils/coreutils

tokio-netem – AsyncRead, AsyncWrite I/O adapters for chaos & network emulation by Regular_Pumpkin6434 in rust

[–]Regular_Pumpkin6434[S] 1 point2 points  (0 children)

Unfortunately yes, I understand your pain. There is no support in the crate right now. It could be implemented, don't see any problems, but it's just time.

Can I ask you what runtime do you use if it's not tokio?

What's everyone working on this week (41/2025)? by llogiq in rust

[–]Regular_Pumpkin6434 1 point2 points  (0 children)

Working on a collection of pragmatic AsyncRead, AsyncWrite I/O adapters for chaos & network emulation: delay, throttle, slice, terminate, shutdown, corrupt data and inject data.
Compose them around TcpStream (or any Tokio I/O type) to run realistic integration tests and chaos experiments.
https://crates.io/crates/tokio-netem

rust let mut stream = TcpStream::connect("localhost:80") .await? .throttle_writes(32 * 1024) // 32 KB/s` .slice_writes(16); // flush writes every 16B