[IshKebab]

> Even the simple, Unix-esque atomic programs can’t help but do two or three things at once. Okay, now you set it up so, instead of waiting on read or accept or whatnot, you register your file descriptors into poll and wait on that, then switching on the result of poll to figure out what you actually want to do.

> Eventually, two or three sockets becomes a hundred, or even an unlimited amount. Guess it’s time to bring in epoll! Or, if you want to be cross-platform, it’s now time to write a wrapper around that, kqueue and, if you’re brave, IOCP.

This feels like a straw man. Nobody is saying "don't use async; use epoll!". The alternative to async is traditional OS threads. This option is weirdly not mentioned in the article at all.

And yes they have a reputation for being very hard - and they can be - but Rust makes traditional multithreading MUCH easier than in C++. And I would argue that Rust's async is equally hard.

Rust makes traditional threading way easier than other languages, and traditional async way harder than other languages, enough that threads are arguably simpler.

[conradludgate]

It's necessary to use some kind of poll construction if you want cancellation and timeouts without shutting down the entire application

[IshKebab]

True but you can still do that using traditional threads using cancellation tokens.

In some ways it's worse because you have to explicitly add them, and I have yet to see any Rust APIs that actually use them (though there is a `cancellation` crate so at least some must be).

In other ways it's better because it gives you control and explicit visibility over the cancellation points.

[conradludgate]

Do you have a source on these cancellation tokens for threads?

The cancellation crate hasn't been touched since 2016 and requires the running thread have a mechanism to be woken up. If you're in the middle of a read, you won't observe a wakeup unless you use an async-io function that can be timed out or interrupted.

This is no better than async/await. And await is just as obvious of the cancellation points.

That being said, there are also numerous crates for async rust cancellation tokens that can polled in parallel with a read such that you can observed the cancel instantly and switch to a cleanup process instead of immediately cancelling everything

[vc8f6vVV]

Channel with an additional thread for sleep? Waiting for a channel is not a poll.

[conradludgate]

You either wait on the channel or wait on a read. How do you manage both?

[vc8f6vVV]

You wait on a shared channel so both read and sleep threads queue a message when ready (whichever comes first). Not sure about channels, but in other languages it would be a concurrent queue.

[conradludgate]

This won't cancel the read, it'll just ignore the result

[vc8f6vVV]

Most languages I know allow killing a thread, or at least unblock a system call.