Comparison of Rust async and Linux thread context switch time and memory use

Re:Comparison of Rust async and Linux thread context switch ... by masklinn on Friday February 12, 2021 @04:55AM (#26112034)

> A classically threaded program can easily block on a future, but wrapping a blocking call in an otherwise asynchronous program is complicated, expensive and error prone work.

It’s really not though, at least as long as the parameters and results are Send. For instance Tokio has a spawn_blocking which runs the function on one of the blocking threads it spawns on-demand specifically for that use.

Meanwhile « blocking on a future » requires adding and managing an entire async runtime and its interactions with the rest of the program, and locking up the runtime is a very real possibility.

[ Parent | on HN ]

Re:Comparison of Rust async and Linux thread context switch ... by josephg on Friday February 12, 2021 @07:52AM (#26113088)

I understand the desire to stave off dependencies but managing an async runtime should only be a simple function call or two. How do you end up locking up the runtime with something like that?

[ Parent | on HN ]