Re:Building a shared vision for Async Rust
by dodobirdlord on Friday March 19, 2021 @01:34AM
(#26510403)
That would have to be determined at the discretion of the implementer of the library. Rust is after all capable of being used to write code that will run in a context where there is no kernel and thus no syscalls.
[ Parent
| on HN ]
Re:Building a shared vision for Async Rust
by millstone on Friday March 19, 2021 @02:51AM
(#26510669)
I don't get it - what library? I may have an `async` function and this is part of the Rust language, not tied to any library. Can I make it into a blocking function without 100% CPU?
"async/await" is just syntactic sugar for a function that returns a Future plus a state machine at yield points. You need a library (executor) to run that Future (execute that function).
The Rust standard library's block_on uses a global ThreadPool, and the docs recommend using a LocalPool if you need finer grained control.
So, to answer your question it depends on the executor (the thing that implements block_on).
Re:Building a shared vision for Async Rust
by steveklabnik on Friday March 19, 2021 @09:41AM
(#26513189)
(To be clear, block_on is not in the Rust standard library.)
ah, darn, thanks!
So for anyone reading for the correct details: the block_on I was thinking of is part of the futures crate, which is not in std, it's not an "official library".
Re:Building a shared vision for Async Rust
by steveklabnik on Friday March 19, 2021 @10:59AM
(#26514088)
It's all good! It was proposed, but decided to have an RFC first. Your point is still correct, just wanted to make sure to clarify this detail :)