Using the C++ Sender/Receiver Framework: Implement Control Flow for Async Processing - Steve Downey

www.cppnow.org​
/ cppnow
---
Using the C++26 Sender/Receiver Framework to Implement Control Flow for Async Processing - Steve Downey - CppNow 2023
Slides: github.com/boostcon
---
P2300 `std::execution` has been forwarded from the Standard C++ Committee's Library Evolution Working Group (LEWG) for inclusion in C++26, meaning that it is design complete and that the Working Group intends this to be in. The design has had practical implementation experience in C++, and has a solid basis in theory. The model has also been used in other languages, and many patterns can be carried over. However, in many ways, the proposal is refreshingly minimal. It specifies what is absolutely necessary -- and little more -- to build programs using structured concurrency. However, this does make it difficult to see how the pieces fit together. This talk will show how the components and connectors for C++26's Sender/Receiver framework are intended to fit together.
The speaker will demonstrate how the minimal parts can be assembled into the standard structured programming patterns, and how they can be used for both static and dynamic control of async and parallel flows. For most programmers, Senders are the abstraction with which they will work. Creating Senders, transforming Senders with ordinary functions, and composing functions that return Senders, all of these are at the heart of the model. The last one is critical, as it enables decisions of where to Send based on the current state.
The talk will first touch on programming language theory to provide some frame of reference and existing vocabulary, as well as highlight some implementations of the model in other languages. Understanding the vocabulary and points of isomorphism will make it easier to see where we can beg, borrow, and steal to solve our problems. When we can see how the Sender/Receiver model is based in existing theory and practice, it is easier to take that work and implement those ideas in our code.
At ground level, this talk will demonstrate how to use the Sender adaptors, such as `execution::then`, `execution::split`, `execution::when_all`, and `execution::let_*`, and the Sender factories, such as `execution::just` and `execution::schedule` to build basic programming patterns like `stmt1; stmt2;`, `if (cond) {/* /}`, `while(cond){/ */}`, as well as more interesting ones like fork/join and backtracking.
We will also show how you might use the framework in existing code without needing to entirely rewrite your program.
---
Steve Downey
Steve Downy has been a programmer for more than 30 years. Steve graduated from SUNY Purchase with a BS in Mathematics. A Computer Science degree would have involved two classes before 11:00 am, so was impossible.
He has worked at Bloomberg since 2003, and is currently working as an Engineer on the C++ Infrastructure team.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
CZcams Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org​
/ cppnow
---
#boost #cpp #cppprogramming

[@JohnWilliams-gy5yc]

I think the commitee should uniformly idiomize the functor fmap and the monad bind functional names across the standard. The let_value should be and_then like in and . I understand that it might too haskell-mimic somewheat but it's less burden to pick up and more useful in the big picture.

[@zenjasolaja9527]

Its a shame that academia and the tech press do not talk about the concept of Actors, which naturally expresses concurrency and communication in a much simpler way to comprehend. We have seen so many complex solutions, yet the simpler abstraction (Actors) seems to be ignored by so many very experienced engineers. There are C++ Actor libraries, but nothing standardised. Maybe in C++4z.

[@simonfarre4907]

Also, doesn't Actors seem much more reasonable than senders and receivers for literally _all_ the examples I see, of senders/receivers in c++ where they talk about async? All the talks of channels, show examples of where the actual readers somewhere will block - which isn't solving async problems, it's solving processing things in batches-problems, where a single consumer consumes results, which is a fairly trivial task to solve ad hoc, where as actors actually are more geared towards a completely async system where there is no "main thread" as it were, no?

[@germandiagogomez]

These are just simple examples. You do not need to block necessarily unless you need that value. I think this library is meant as a low level runtime to build other things on. As such, it provides the building blocks. Actors seem to me like more comfortable to use but also more intrusive and need more runtime to run, like boxes and stuff like that. Nothing would prevent you to build an actor run-time on top of these things.

[@SamualN]

wow javascript's async await really caught on huh

[@Voy2378]

so disappointed with ugly free function syntax... wtf are they doing this? member fns make code nicely left to right readable.