This is one reason why I built coroutines into my game programming language Easel (https://easel.games). I think they let you keep the flow of the code matching the flow of the your logic (top-to-bottom), rather than jumping around, and so I think they are a great tool for high-level programming. The main thing is stopping the coroutines when the entity dies, and in Easel that is done by implying ownership from the context they are created in. It is quite a cool way of coding I think, avoids the state machines like the OP stated, keeps everything straightforward step-by-step and so all the code feels more natural in my opinion. In Easel they are called behaviors if anyone is interested in more detail: https://easel.games/docs/learn/language/behaviors
Looking at Unity made me understand the point of C++ coroutines
131–140 of 190 posts
Re: Looking at Unity made me understand the point of C++ coroutines
#132Earlier quoted context omitted.
> I'm not normally keen to "well actually" people with the C standard, but .. if you're writing in assembly, you're not writing in C. These days on Linux/BSD/Solaris/macOS you can use makecontext()/swapcontext() from ucontext.h and it will turn out roughly the same performance on important architectures as what everyone used to do with custom assembly. And you already have fiber functions as part of the Windows API t…
Unfortunately swap context requires saving and restoring the signal mask, which, at least on Linux, requires a syscall so it is going to be at least a hundred times slower than an hand rolled implementation. Also, although not likely to be removed anytime soon from existing systems, POSIX has declared the context API obsolescent a while ago (it might actually no longer be part of the standard).
Stackful coroutines also can't be used to "send" a coroutine to a worker thread, because the compiler might save the address of a thread local variable across the thread switch (happened in QEMU).
Re: Looking at Unity made me understand the point of C++ coroutines
#133Earlier quoted context omitted.
Signal mask? What century are we in? It can be safely ignored for the vast majority of apps. If you're using multithreading (quite likely if you're doing coroutines), then signals are not a good fit anyway.
Aside from the fact that the signal mask is still relevant in 2026 and even for multithreaded programs, that doesn't have anything to do with the fact that POSIX requires swapcontext to preserve it.
In most cases you're already using signalfd in places where libdex runs.
Re: Looking at Unity made me understand the point of C++ coroutines
#134You can roll stackful coroutines in C++ (or C) with 50-ish lines of Assembly. It's a matter of saving a few registers and switching the stack pointer, minicoro [1] is a pretty good C library that does it. I like this model a lot more than C++20 coroutines: 1. C++20 coros are stackless, in the general case every async "function call" heap allocates. 2. If you do your own stackful coroutines, every function can suspend…
Actually you don't even need ASM at all. Just need to have smart use of compiler built-in to make it truly portable. See my composable continuation implementation: https://godbolt.org/z/zf8Kj33nY
Re: Looking at Unity made me understand the point of C++ coroutines
#135Earlier quoted context omitted.
I only mentioned co_yield() since that's what the article was (ab)using, although perhaps justifiably so. It seems the coroutine support was added to C++ in a very flexible way, but so low level as to be daunting/inconvenient to use. It needs to have more high level facilities (like Generators) built on top. What I was thinking of as a state machine with using std::future was a single function state machine, using sw…
> as to be daunting/inconvenient to use I don't even know how to respond to that. How in the world are you using C++ professionally if you think coroutines are "daunting"? No one uses C++ for it's "convenience" factor. We use it for the power and control it affords. > What I was thinking of as a state machine with using std::future was a single function state machine, using switch (state) to the state specific dispat…
So it's meant to be inconvenient, and that's the only right and proper way?!
Sounds more like punishment than software design, but each to their own.
Re: Looking at Unity made me understand the point of C++ coroutines
#136Most game engines seem to have some coroutine kludge.
Re: Looking at Unity made me understand the point of C++ coroutines
#137> turns it into some sort of ugly state machine
Why are people afraid of state machines? There's been sooo much effort spent on hiding them from the programmer...
Re: Looking at Unity made me understand the point of C++ coroutines
#138I've been doing a lot of work with ECS/Dots recently and once I wrapped my head around it - amazing.
I recall working on a few VR projects - where it's imperative that you keep that framerate solid or risk making the user physically sick - this is where really began using coroutines for instantiating large volumes of objects and so on (and avoiding framerate stutter).
ECS/Dots & the burst compiler makes all of this unnecessary and the performance is nothing short of incredible.
Re: Looking at Unity made me understand the point of C++ coroutines
#139Earlier quoted context omitted.
Just out of interest, how many serious unity devs have you talked to?
I've talked to some non-serious unity devs, like Peter Molyneux... https://news.ycombinator.com/item?id=47110605 >1h 48m 06s, with arms spread out like Jesus H Christ on a crucifix: "Because we can dynamically put on ANY surface of the cube ANY image we like. So THAT's how we're going to surprise the world, is by giving clues about what's in the middle later on." https://youtu.be/24AY4fJ66xA?t=6486 Click. Click. Clic…
Lol. I met him at a Unity Conference in Amsterdam I think it was 2013? To be honest I was a bit star struck, but then I saw the scandal of that click click click cube... something about careful about meeting your heroes...
Re: Looking at Unity made me understand the point of C++ coroutines
#140I don't know, I'm not convinced with this argument. The "ugly" version with the switch seems much preferable to me. It's simple, works, has way less moving parts and does not require complex machinery to be built into the language. I'm open to being convinced otherwise but as it stands I'm not seeing any horrible problems with it.
Switch is fine until you hit five or six states with cleanup in each branch. Then it's just a worse version of what coroutines give you for free.