|
|
|
|
|
by choochootrain
2671 days ago
|
|
its a two-edged sword. if you can trust the application code to effectively schedule itself then it's good but you can also get bugs and perf issues where a synchronous chunk of code blocks progress on everything (see js blocking the main thread and causing the ui to freeze) the pro is that your async code explicitly defines points where context switching is okay since you're blocking on something anyways. this could be good for perf if context switching in the middle of a synchronous operation is expensive. the con is that your async code might not cede control often enough to allow other coroutines to make progress. so yes, you can have something hogging the runtime but in the context of an application that you control as a whole this is something you can avoid/fix if necessary. at the OS level this might not make sense because you have to assume that applications are adversarial and will try to hog cpu time... |
|