3 ms·
I keep having to repeat it on this unfortunate website: it's an implementation detail, a multi-threaded executor of async/await can cope with starvation perfect
by neonsunset 3y ago
I keep having to repeat it on this unfortunate website: it's an implementation detail, a multi-threaded executor of async/await can cope with starvation perfectly well as demonstrated by .NET's implementation that can shrug off some really badly written code that interleaves blocking calls with asynchronous.
https://news.ycombinator.com/item?id=39530435 https://news.ycombinator.com/item?id=39530435
https://news.ycombinator.com/item?id=39786142 https://news.ycombinator.com/item?id=39786142
https://news.ycombinator.com/item?id=39721626 https://news.ycombinator.com/item?id=39721626
- AstralStorm 3y agoSaid badly with code will still execute with poor performance and the mix can be actively hard to spot.
- neonsunset 3y agoYou would be surprised. It ultimately regresses to "thread per request but with extra steps". I remember truly atrocious codebases that were spamming task.Result everywhere and yet there were performing tolerably even back on .NET Framework 4.6.1. The performance has (and often literally) improved ten-fold since then, with threadpool being rewritten, its hill-climbing algorithm receiving further tuning and it getting proactive blocked workers detection that can inject threads immediately without going through hill-climbing.
- maccard 3y agoBadly written threaded code will have the same problem, unfortunately