Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tokio/Rayon Trap and Why Async/Await Fails Concurrency

pmbanugo.me

Post reply on HN
Print view View original

61–63 of 63 posts

Re: The Tokio/Rayon Trap and Why Async/Await Fails Concurrency

#61

Post by swiftcoder »

haberman wrote: post #16

I see two solid points here: 1. It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts. 2. It's not reasonable to queue up an arbitrary amount of work without back-pressure. I haven't used Tokio much, but if it falls prey to these pitfalls, it would make me pause before adopting it. I think there are probably ways of using Rust async that don't fall…

> It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.

If your application has both of these and doesn't partition them, you already have a fundamental flaw in your application architecture. Every serious piece of software does this, from web GUIs, to servers, all the way to video games.

> It's not reasonable to queue up an arbitrary amount of work without back-pressure

Absolutely, which is why we use pull-futures instead of push-futures, across the entire rust ecosystem. Creating unbounded queues in Tokio requires a fair bit of error on the part of the programmer

Re: The Tokio/Rayon Trap and Why Async/Await Fails Concurrency

#63

Post by didibus »

oersted wrote: post #31
didibus wrote: post #29

Earlier quoted context omitted.

I'm not 100% sure, but it looks like Tina forces your IO to be return values. You can't actually do IO inside the Isolate handlers, so your compute code runs and returns the next IO operation to run. That's what it meant by you need to be explicit about the state machine, you have to have a handler for before I make this IO, and a handler for after that IO has run. Isolates are like synchronous state machines. During…

That does clarify some things, but still. Say you have an Isolate pinned to a core and it's doing some long compute. In the meantime some background IO finished and an Isolate in the same core needs to handle the result. That will not happen until the long compute is done. Isn't it just like in async and any other cooperative concurrency model? At least in multi-core async, that message can be handled in a different…

Correct, the claim here is that this is better because cache locality is too big a hit and not worth the trade off. I don't know if this is true or not and likely depends on workload.

I think they might say you need to rewrite your long-compute to have explicit yield points. Say you are parsing many rows, you'd explicitly yield after every 100 rows for example.

Post reply on HN