3 ms·
I think with all the async / await noise, the simplicity of co-routines is usually forgotten. IMHO, they are the right abstraction on top of event-loops. Every
by crudbug 9y ago
I think with all the async / await noise, the simplicity of co-routines is usually forgotten.
IMHO, they are the right abstraction on top of event-loops. Every major server platform, especially - JVM, CLR, should support them.
I would be very much interested in context-switch data of server applications for Threads vs. Coroutines loads.
- vvanders 9y agoYup, I never understand the need to bring a heavyweight thread to bear when coroutines are the actual semantics that most people want. It's one of my favorite features of Lua and lets you do async-anything in a really nice and clean manner with minimal overhead.
- tobz 9y agoI'd say that this is roughly the case with .NET, in terms of async/await. IIRC, you're using a thread pool under the hood, and you sort of have to opt-in: if you're trying to write your own async code, for example, you need to schedule it in a way that's slightly more complicated than just saying `go myFunc()`, but it's possible. As for the JVM, libraries like Akka and Quasar already provide this, although possibly not as performantly as if the runtime itself provided it?
- int_19h 9y agoStrictly speaking, whether you're using the thread pool under the hood or not depends on the task scheduler, which is pluggable. The default one that new threads get is indeed going to dispatch to the thread pool (on different threads at that, not the same one). But it can be pretty much anything. Async/await doesn't really care about any of that, it just creates continuations for you, and hands them over to the scheduler.