Comment by arijun
3 years ago
Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
3 years ago
Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
"Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable.
It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
Isn't this the difference between concurrency and parallelism? Like you said, Tokio (I'm coming from effect systems in Scala, the current generation of which take heavy inspiration from Tokio) is good for informing your program when your code is blocked so it can perform some useful work elsewhere, which is a fundamentally different problem to parallelizing code. So if I'm understanding your complaint right it's that Tokio sneaks in when its concurrency features aren't particularly useful for parallelization?
Correct.
I have an unusual application, a metaverse client for big 3D worlds. It has to deal with a flood of data while maintaining a 60 FPS frame rate. It's essential that the rendering thread(s) not be delayed, even though other background threads are compute bound dealing with a flood of incoming 3D assets. This does not fit well with the async model.
This sort of thing comes up in games, real time control, and robotics, but is not something often seen in web-related software.
1 reply →
Not OP, but I think the problem they are trying to explain is that if you create an async function it can only be called from other async functions, so it's quite an infectious concept.
If you create a library that uses async, you're forcing everybody that uses the library into async as well (with the same executor).
If somebody writes a library now that's generally useful but uses async, it forces others to use async or rewrite the library themselves.
On the one hand a lot of people put this down as whining about free code, which is somewhat true, but the infectious nature makes the whole ecosystem less useful if you want to build something non-async.
1 reply →