C++20’s Coroutines for Beginners - Andreas Fertig - CppCon 2022 

My pleasure! Thank you!

To understand coroutines you don't need any multithreading or async. Don't know where this idea is coming from. They are just functions. So you need understand function frames the stack/automatic variables and lambdas. It's just very bad taught so far. They are a state machine and you have to give some code points to the compiler.

It's really not that complex. It's literally just a function which you can suspend and jump out of and then jump back in and continue where you left off.

After having to tweak a coroutine once for work, I’ve watched a bunch of videos to try to understand the concepts and how they work. Most videos have been confusing. Some I kind of get. One explained it in a way that made it easy to understand, talking about things like the way the compiler sees things and what-not, with the audience asking great questions, and it really was simple. I think the problem with a lot of videos is they start with use cases (sometimes good ones) without explaining what coroutines are first. It’s as simple as Invader said, as a tool, a coroutine is a function that can suspend and resume itself, can be resumed, and can optionally return data. That’s it at its core. Part of what I think makes it off-putting is I’m not used to functions being able to exit mid-function and then resume later. It stores its local data in a frame, that in C++ is usually stored on the heap (making it “stackless”). The compiler adds control code to the function that, for me, knowing made it easier to understand. What makes it important are its use cases. There 2 I keep seeing come up. As a generator where you repeatedly call it to generate the next piece of data, such as in a sequence. And, when paired with a good multi-threaded scheduler, as a task that lets you write a chain of asynchronous calls in the way you would normally write blocking synchronous ones, making it easier to read, but without actually blocking (because of the suspend and resume functionality). Since coroutines themselves are really flexible, I’m sure there’s other use cases. I’m still watching videos to learn more, and I still find many confusing even after learning the basics. I think a lot of it is using them requires thinking differently and they presume you know things you don’t or try to explain them in the context of confusing use examples. Many presume a multi-threaded scheduler but don’t explain it because libraries like Boost come with one, but while useful with coroutines, are not apart of coroutines themselves. That’s been my experience so far. I’m not sure how clear I was as I’m still a novice with coroutines, but hopefully it’s helpful to someone. I’m going to go watch my next video to see if I can learn more.

I hope you enjoyed both. This talk uses a different approach and different examples compared to the one in my C++20 book.

Very pleased to hear that the presentation was helpful.

Thank you! That means a lot to me!

I agree. Being new to C++ Coroutines I found this very helpful.

Thank you! I'm very pleased to hear that you liked my presentation.

I'm glad I could shed some light on coroutines!

I'm glad you enjoyed my presentation!

Your comments are much appreciated, thank you.

Great! I'm glad that I could show the powers of coroutines.

"primary benefit of coroutines is essentially to combine the tasks of two threads into a single thread. " Well, my use case was to use coroutines to buffer reads from the Web and writes to a database. Where the cooroutine would make the request and yield to the thread while awaiting the results of the http request, or the write to the DB. (I did this in GoLang where there is less customization, in fact almost none, and what seems like less boilerplate.). The general theory is that you use a cooroutine where the cost of the call is significant, ie the program could do useful work while awaiting the result. The way GoLang recommends communication with the coroutine is through a "channel" which is essentially a vector with a mutex on it.

I believe that the fact that final_suspend() returns std::suspend_never (slide 27) indicates to the compiler to destroy the frame (and destruct the promise) when the coroutine ends

No it will leak if you don't provide promise_type::return_void(). That's why you wrap your coroutine handle and provide all the fancy destructor / std::exchange stuff.

This is just the framework around which the ready solution wilk be built (it is comming in c++ 23 as far as I know). The availability of the underlying framework allows some really crazy shit such as sharing a single thread between multiple coroutines or batching yielded results before actually suspending.

python's coroutines create their own stack, so are huge and clunky when speed is required like, f(i for i in range()) can be a lot slower than f([i for i in range()]) just because of all generator's use (and that's without comparing creation costs) c++ coroutines are bone structure for multiple high speed applications and normal users will get their std::generator in ++23

For historical reasons probably. C++ is a really old language and keeping it modern is really hard.

You get convience by sacrificng performance in some cases, for most programmers its enough. But C++ is for those who might need performance in those cases, and thats why it looks how it looks.

Not if it's just a presentation

this isn't python's generators that would be ++23's std::generator these coroutines are bone structure for many more, much faster constructions

Could you point me to the rust coroutines? Last time I was looking there were none.

What you are used to is always easier than something you have to learn first. That's why "easy" often is not a quality criterion, in neither direction. After having written the wrapper type ("Chat"), writing different coroutines is much easier than writing different classes for implementing different behaviours.

while I agree I hope you first read some boost asio code so you will see things can be much much worse...

What the committee has done is to provide: a) a transformation of the code that uses co_await, co_yield and co_return. b) a way to save and restore the CPU context. That's all they did. The actual implementations are left to the user of the language, i.e. the provider of libraries. Eventually the language will provide simple coroutine objects, but first they need to provide the low level API. You can certainly do without coroutines...if I need to program my own object that generates numbers or iterates a vector or two vectors, why not simply write an object that does the job and holds the appropriate state? But then there is stuff like the scheduler and tasks which are not doable with simple objects, because c++ does not provide an official way to save and restore contexts (there is stuff from C, like getjmp/setjmp, but that has a lot of limitations). C++ co-routines can do this kind of task scheduling though, because they keep the appropriate contexts and allow suspension and resumption of those contexts.