alternative to select

[dvdsk]

Hi there, lovely TUI. I was browsing through the code to steal your systemd interface :) for my installer builder crate (which now calls systemctl and parses its output).

I noticed this comment:

systemctl-tui/src/systemd.rs

Line 217 in feb0c47

// god these select macros are ugly, is there really no better way to select?

I wonder if futures_concurrency might offer a good fit? I really like it myself.

Thats all.

Have a great day!

Edit:
select is called race in futures_concurrency

[rgwood]

Hey, thanks for the kind words and the heads up.

I might be missing something but I don't see a drop-in replacement for the Tokio select! macro in futures_concurrency 🤔

[dvdsk]

I might be missing something but I don't see a drop-in replacement for the Tokio select! macro in futures_concurrency 🤔

the idea is to make sure both futures have the same return type and then race on them. That race you can .await. You then match on the result.

Example for the code snippet above would be:

pub async fn stop_service(service: UnitId, cancel_token: CancellationToken) -> Result<()> {
	// ...
	enum RaceResult {
		Cancelled,
		Complete,
	}

	match (
		stop_service(service).map(RaceResult::Complete),
		cancel_token.cancelled().map(RaceResult::Cancelled)
	) {
		RaceResult::Cancelled => anyhow::bail!("cancelled"),
		RaceResult::Complete(result) => result,
	}
}

Instead of defining your own enum RaceResult you could also use Either from the Either crate. This same pattern (map the futures then pattern match in normal code) is also seen on embedded systems, see https://docs.embassy.dev/embassy-futures/git/default/select/index.html. Though there they do not use a trait over tuples/arrays/Vec like with futures_concurrency.

There is also a blog post series over the crate (though some things have been renamed since writing): https://blog.yoshuawuyts.com/futures-concurrency/