| ▲ | nananana9 4 hours ago |
| You 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/resume, you don't have to deal with colored functions. 3. (opinion) C++20 coros are very tasteless and "C++-design-commitee pilled". They're very hard to understand, implement, require the STL, they're very heavy in debug builds and you'll end up with template hell to do something as simple as Promise.all [1] https://github.com/edubart/minicoro |
|
| ▲ | MisterTea 4 minutes ago | parent | next [-] |
| A much nicer code base to study is: https://swtch.com/libtask/ The stack save/restore happens in: https://swtch.com/libtask/asm.S |
|
| ▲ | pjc50 4 hours ago | parent | prev | next [-] |
| > You can roll stackful coroutines in C++ (or C) with 50-ish lines of Assembly 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. And the obvious consequence is that it stops being portable. Minicoro only supports three architectures. Granted, those are the three most popular ones, but other architectures exist. (just double checked and it doesn't do Windows/ARM, for example. Not that I'm expecting Microsoft to ship full conformance for C++23 any time soon, but they have at least some of it) |
| |
| ▲ | blacklion 19 minutes ago | parent | next [-] | | There is no "Linux/ARM[64]". But there are "Raspberry Pi" and "RISC-V". I don't know such OSes, to be honest :-) This support table is complete mess. And saying "most platforms are supported" is too optimistic or even cocky. | |
| ▲ | manwe150 3 hours ago | parent | prev | next [-] | | Boost has stackful coroutines. They also used to be in posix (makecontext). | |
| ▲ | fluoridation 3 hours ago | parent | prev [-] | | I think what they meant is that that what it takes to add coroutines support to a C/++ program. Adding it to, say, Java or C# is much more involved. |
|
|
| ▲ | Sharlin 3 hours ago | parent | prev | next [-] |
| C++ destructors and exception safety will likely wreak havoc with any "simple" assembly/longjmp-based solution, unless severely constraining what types you can use within the coroutines. |
| |
| ▲ | fluoridation 2 hours ago | parent [-] | | Not really. I've done it years ago. The one restriction for code inside the coroutine is that it mustn't catch (...). You solve destruction by distinguishing whether a couroutine is paused in the middle of execution or if it finished running. When the coroutine is about to be destructed you run it one last time and throw a special exception, triggering destruction of all RAII objects, which you catch at the coroutine entry point. Passing uncaught exceptions from the coroutine up to the caller is also pretty easy, because it's all synchronous. You just need to wrap it so it can safely travel across the gap. You can restrict the exception types however you want. I chose to support only subclasses of std::exception and handle anything else as an unknown exception. | | |
| ▲ | pjc50 2 hours ago | parent | next [-] | | > Passing uncaught exceptions from the coroutine up to the caller is also pretty easy, because it's all synchronous. You just need to wrap it so it can safely travel across the gap This is also how dotnet handles it, and you can choose whether to rethrow at the caller site, inspect the exception manually, or run a continuation on exception. | |
| ▲ | Sharlin 2 hours ago | parent | prev [-] | | Thanks, that's interesting. |
|
|
|
| ▲ | Joker_vD 4 hours ago | parent | prev [-] |
| Hmm. I'm fairly certain that most of that assembly code for saving/restoring registers can be replaced with setjmp/longjmp, and only control transfer itself would require actual assembly. But maybe not. That's the problem with register machines, I guess. Interestingly enough, BCPL, its main implementation being a p-code interpreter of sorts, has pretty trivially supported coroutines in its "standard" library since the late seventies — as you say, all you need to save is the current stack pointer and the code pointer. |
| |
| ▲ | zabzonk 4 hours ago | parent | next [-] | | You can do a lot of horrible things with setjmp and friends. I actually implemented some exception throw/catch macros using them (which did work) for a compiler that didn't support real C++ exceptions. Thank god we never used them in production code. This would be about 32 years ago - I don't like thinking about that ... | |
| ▲ | lelanthran 4 hours ago | parent | prev | next [-] | | > Hmm. I'm fairly certain that most of that assembly code for saving/restoring registers can be replaced with setjmp/longjmp, and only control transfer itself would require actual assembly. Actually you don't even need setjmp/longjmp. I've used a library (embedded environment) called protothreads (plain C) that abused the preprocessor to implement stackful coroutines. (Defined a macro that used the __LINE__ macro coupled with another macro that used a switch statement to ensure that calling the function again made it resume from where the last YIELD macro was encountered) | | | |
| ▲ | gpderetta 4 hours ago | parent | prev [-] | | setjmp + longjump + sigaltstack is indeed the old trick. |
|
