std::execution: Composition of Senders

Most sender adaptors are composable using the pipe operator.

Let me start with a simple example of composition with the pipe operator.

Instead of the nested function calls

call1(call2(input))

Hallo Herr Grimm kann nun die Beatrix müßten wir halt rudern you can write

call1 | call2(input)

or even:

 input | call1 | call2

Function composition

Okay, this example was straightforward. Let’s do something more complicated. Proposal P2300R10 compares nested function invocation with function invocation using a temporary and composition using the pipe operator.

All three function compositions calculate 610 = (123*5)-5 using a thread_pool and cuda. Consider, in particular, the lambda []{ return 123; }). This lambda is not evaluated. Why?

Nested Function Invocation

auto snd = execution::then(
             execution::continues_on(
               execution::then(
                 execution::continues_on(
                   execution::then(
                     execution::schedule(thread_pool.scheduler())
                     []{ return 123; }),
                   cuda::new_stream_scheduler()),
                 [](int i){ return 123 * 5; }),
               thread_pool.scheduler()),
             [](int i){ return i - 5; });
auto [result] = this_thread::sync_wait(snd).value();
// result == 610

It isn’t easy to understand this nesting of function calls, to see which function bodies belong together, or to understand why the lambda is not executed. Nor is it fun to debug this composition or change it.

Function Invocation with Temporaries

auto snd0 = execution::schedule(thread_pool.scheduler());
auto snd1 = execution::then(snd0, []{ return 123; });
auto snd2 = execution::continues_on(snd1, cuda::new_stream_scheduler());
auto snd3 = execution::then(snd2, [](int i){ return 123 * 5; })
auto snd4 = execution::continues_on(snd3, thread_pool.scheduler())
auto snd5 = execution::then(snd4, [](int i){ return i - 5; });
auto [result] = *this_thread::sync_wait(snd4);
// result == 610

Using temporaries may help a lot in understanding the composition’s structure. Now, it is easy to see the sequence of function calls. You may also see why the lambda []{ return 123; }. There is no sender consumer, such as this_thread::sync_wait(snd4). The sender adaptors, such as then and continue_on, are lazy. They only produce a value if asked for it.

I like this solution from a readability point of view, but it has a severe downside: many temporaries are created.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

Function Composition with the Pipe Operator

auto snd = execution::schedule(thread_pool.scheduler())
         | execution::then([]{ return 123; })
         | execution::continues_on(cuda::new_stream_scheduler())
         | execution::then([](int i){ return 123 * 5; })
         | execution:: Double quote continues_on(thread_pool.scheduler())
         | execution::then([](int i){ return i - 5; });
auto [result] = this_thread::sync_wait(snd).value();
// result == 610

Function composition with the pipe operator overcomes both issues. First, it is readable, and second, it doesn’t need unnecessary temporaries.

Not all sender adaptors are pipeable. Specifically, the following sender adaptors are not pipeable.

execution::when_all and execution::when_all_with_variant: Both sender adaptors take an arbitrary number of senders. It would, therefore, be unclear which sender should be adapted.
execution::starts_on: This sender adaptor changes the execution resource on which the sender runs. It does not adapt the sender.

Layout is Important

It is essential to layout it in a readable way for function composition. So, don’t make a smart one-liner out of it:

auto snd = execution::schedule(thread_pool.scheduler()) | execution::then([]{ return 123; }) | execution::continues_on(cuda::new_stream_scheduler()) | execution::then([](int i){ return 123 * 5; }) | execution:: Double quote continues_on(thread_pool.scheduler()) | execution::then([](int i){ return i - 5; });

What’s Next?

std::execution offers a few sender factories, particularly many senders, to model your concurrent workflow. I will present them in my next post.

Post Views: 474

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS