Hacker News Reader

Comment by billllll | Hacker News Reader

Someone please correct me if I'm wrong, but Rust async/await isn't implemented with green threads, but with OS threads. Those can be pre-empted.

View on HN

Async/await does not use threads of any kind. It creates a state machine.

Executors may execute those state machines on a single thread, or map them to many threads. The latter looks kinda like green threads depending on what your definition of “green thread” is.

It's single threaded and completely userspace. Rust async/await is a fancy way to write poll/epoll. It can limit the amount of time your program is blocked on IO (insofar as the implementation is as you would expect it (not guaranteed by the language)), but it will not do parallelism. For example you wouldn't async/await a prime number calculation--you'd have to use OS threads.

It’s not necessarily single threaded; Rust async runtimes typically schedule tasks on a pool of multiple OS threads, usually one thread per CPU core. In other words, it can be seen as a form of M:N threading.

Regarding the parent’s question, tasks cannot be preempted from their threads. Threads can of course be preempted from their CPU cores by the OS, but if the number of threads equals the number of cores, this will only happen if other processes on the system are competing for CPU time.

nothing about how it works is built into the language, its up to user code/libraries to decide how to do it.

the popular libraries like tokio are using something akin to green threads, though people picky about definitions may not agree to that nomenclature.

> nothing about how it works is built into the language

I think the state machine required to yield, async & await is baked into the language.

But yes, one can implement the Future trait to take finer control.

Reply on news.ycombinator.com