Deciphering C++ Coroutines - A Diagrammatic Coroutine Cheat Sheet - Andreas Weis - CppCon 2022

[@OptimusVlad]

I used to think, like others (apparently), that coroutines seem way more complex than they needed to be. But, as I learn more about them, I realize that this language feature was added in such a way as to provide maximum flexibility, so that it could support any type of coroutine-based library that one could think of. It's like how, at the beginning, pointers and templates seem to over complicate things, and then you have an "aha!" moment, and then their complexity makes sense. One of the main ideas that helps me understand the purposes of coroutines is that each coroutine can be used to create related *families* of functions. For example, the Generator coroutine is just 1 coroutine type, but that allows you to create any amount of functions that need to behave like generators. That allows us to place the complexity of yield/waiting within the Generator coroutine, and then each function only needs to deal with generating the actual values. I have no doubt that, as we become more experience in using coroutines as a community, we'll start to see libraries that make novel uses of the machinery that coroutines provide. It's a very powerful feature, but with that power comes associated complexity. There are 2 aspects of coroutines: how to use them, and how to create them. I think it's ok to just learn how to use them at first, and only learn how to create them as you find need for them. Unless, like me, you're intrigued by them, in which case you'll have to deal with the process of learning this powerful feature.

[@mytech6779]

I would only point out that pointers are not high level abstractions adding complexity, on the other hand named objects are abstrations of pointers. It's basically all pointers down at the machine level.

[@OptimusVlad]

This talk is fantastic. It goes through each part of the coroutine machinery in detail. It really helped me understand various things that I was still confused about. However, this is not the best talk for beginners. For someone completely unfamiliar with coroutines, they should watch other beginner talks first, and then come to this one to round out the knowledge. Thank you, Andreas Weis.

[@scofieldlee6512]

The ever best tutorial of c++ coroutines. Visualizing the components and correlations make sense a lot!!!! Thx for amazing talk!

[@TheWayofthecode]

I've watched the talk twice. The second time I understood everything that was presented. Kudos to Andreas Weis for the great presentation.

[@awawus]

This is a very well thought out picture / diagram of the whole coroutine concept. Thank you for the much effort to make this happen. If you are having trouble understanding this wonderful talk, note that these are the building blocks of any coroutine applications. Check first out some finished products of these building blocks like cppcoro and you will notice all the possibilities that these constructs provide.

[@ConceptInternals]

Hey, where to access the slides of this talk? I am unable to find them in the CPPCon 2022 github link provided in the description..

[@Poti221]

Amazing explanation!

[@dexterman6361]

I don't understand something at all. Maybe I have it completely wrong in my head. In C#, you can do await and the execution is resumed when the result of is ready. I know I need to have a monitoring thread that checks if the awaitable is ready and then calls the handle.resume() on it, but how do I know if the awaitable is ready, given a handle? Is my model of thinking about this incorrect? How can I, from a coroutine handle, check if the result of a co_await in the coroutine is ready? Because that is the model of co_await socket.write(data), right? Excellent video, thank you! I still don't get it, like at all, but I think I'm getting closer, if ever so slowly.

[@8Johnny8Catsvill8]

Thank you, very useful lecture

[@shelper]

Not sure if i understand correctly, but seems foundamentally coroutine is just a more elegant way to wrap up the callback. where you have the coroutine handler that connects the caller and callback...

[@SametPilav]

Pushing data into a coroutine and symmetric transter topics were missing parts for me. Thank you for explanation.

[@katanasteel]

Based on this... co-routines seems more like a mutable lambda or a function object with multiple () overloads, with co_return, runs a destructor with a return type ...

[@TheTimur123]

Do I understand correctly that the coroutines allow us to return an unfinished result that will appear in the future, but unlike the standard future promise that we have in std::async, we do not hang on the get() method. Thus, the coroutines allow us to make chains of functions where the result of the first function is not yet ready for processing in the second function, while we do not hang on the get() method waiting for the finished result. The same can be done with monadic chain, when we build a pipeline of transformation chains. It's very similar to a car factory. There is a conveyor and there are many machines. Each machine takes the result from the previous one and passes it to the next one. But when there is no input part yet, the machine is NOT IDLE, it begins to do preparatory operations, for example, before installing wheels, it is necessary to take the correct mounting bolts. There is nothing prevents from taking 20 bolts out of the box for fixing the wheels, even if the wheels has not yet arrived from the air pumping machine, which pumps the wheel with air. Thus, the machine for installing wheels will already have time to do something (in other words, it will start its work even the wheel is not ready yet). As soon as the previous machine gives the finished wheels, the machine that installs the wheels on the car will immediately tighten them with ready at hands bolts, since it has already found and taken these bolts during the time while the previous machine was pumping the wheels. Thus, no one is idle waiting for the result from the previous machine.

[@Bbdu75yg]

Really nice lecture🎉!! Literally “deciphering “ 😂

[@georganatoly6646]

sounds like it exposes a kind of customizable shallow context switching, idk, kind of reads to me like the designers were trying to elevate low level implementation details to a first-class language feature but ended up getting a little too carried away with the gee-wiz of it all

[@PedroOliveira-sl6nw]

I have yet to see a talk about co-routines that explains why I would use a co-routine.

[@OptimusVlad]

What has been helping me with this is writing code to implement little pieces of coroutines. As one gains knowledge of the various pieces, ideas on how to use them will naturally arise.

[@purduetom90]

It’s my understanding it’s so you can make async calls in your code, that appear to be synchronous, without having to implement callbacks. In theory, your code looks sequential and blocking but it’s not. I’m comparing to what I can do in JavaScript, with async/await, compared to using promises with a bunch of “then” statements chained together. However, sure does seem like we have to write a bunch of ReturnType-specific code to accomplish this. I need to understand this better before I’m sold…

[@angelxmod3]

1) Avoid callback hell. I.e, make asynchronous code look synchronous. 2) Implement some sort of lightweight thread 3) implement generators.

[@kiesun3276]

I like coroutine and I have created an echo server with it with wrapping the epoll. But the question is, C++ gives a basic functionality but the exector and utilities around it. The community shows less interest at it. The async ecosystem is even worse than Rust's.

[@randfur]

I wish they showed the Fibonacci generator in the multiple forms with co_await, co_yield and another coroutine.

[@rohitjoshi4341]

Isn't it better to have coroutines use observer pattern with promise being a central point and the coroutines_handler as abstract pattern. This way most of the complexity of the coroutines would be removed for applications developers point of view.

[@NotherPleb]

C++ was able to turn this clean and modern feature into a hot garbage complex mess that nobody will use...

[@Voy2378]

I am a bad student :) but I also think that too much stuff was left out to make it fit in 60 min... Also I would like to see those graphs and sequence diagrams even if author thinks they are inferior to colored code.

[@Dziaji]

This is the best presentation on c++ co-routines that I have seen so far. Unfortunately, it is still complete cryptic garbage and is disjointed and not understandable. All the pieces are described without explaining what they are or why they are necessary or what they have to do with co-routines. I suspect that part of the problem is the over-complication of the language feature, leading to difficulty in properly explaining how it works, but even the most complicated concept can be broken down into pieces and organized into a digestible presentation. While I commend this guy for his effort, the presentation collapses into a jumbled, unintelligible mess of terms that leaves me no closer to being able to read or write co-routine inner workings. Hopefully, someone else will try again. Maybe someone can get Scott Meyers on the job.

[@jopa19991]

Nobody really explains schedulers, and STL also misses at least some generic specification for those. So you have a very featureful tool to stop and resume the function but nobody really explains how to approach to design something that actually executes them! This makes corountines pointless for many potential users.

[@OptimusVlad]

I completely disagree. This talk was fantastic. It's very difficult to learn coroutines without writing test code for implementing coroutines, and trying things out as the various speakers brings them up. Coroutines require experimentation to be propertly understood -- it's not a passive process. I've been listening to as many coroutine talks as I can, and each brings me closer to full comprehension. This talk, in particular, filled out some holes I had in my understanding.

[@DavideLibenzi]

I completely agree. While the talk is nice, and goes very well explaining the "clutter" ... clutter is still clutter. Why did this (as in, coroutines in this form) even got into the C++ standard is hard to explain for me.

[@jtsiomb]

This is all extremely convoluted and unbelievably ugly. I will go to great lengths before I put any of this clusterfuck in my code. I'd rather make a state machine, use an explicit "recursion" stack, or whatever else it takes. Coroutines are powerful as a concept, and can be elegant in a language which fits them. C++ fits the machine, and the machine does not work like that. If you need an hour-long video to explain a single language feature, that should ring an alarm bell. The C++ committee has seriously lost the plot by this point.

[@davidebaldini7830]

From C++98 to C++17 I've been routinely impressed by how carefully each standard specification had been thought thru. The language always stood out for its clarity and precision. With the introduction of forwarding references, C++ lost some points in clarity because arguments of template functions can now forego the const specifier in order to coalesce into the same syntax both l-value references (usually const) and r-value references (usually non const), muddling clarity. The introduction into the standard of trailing declarations (e.g. auto f() -> int) was mostly a hipster stunt to impress the groundlings. But most worryingly, the C++20 and C++23 specifications contributed to by Google are taking the language off its orbit of mental sanity and into utter brainfuckery, with a growing exceptions-to-rules ratio.

[@yaroslavpanych2067]

I have like a ton questions.... however the main point is, it will be ignored for next 10 years, unless someone pays to use it.

[@destiny_02]

megamind

[@vladimiro3059]

very bad explanation. No real samples. I don't recommend this as a starting point for c++ coroutines.