can let_value and split do same thing?

[fililili]

Seems split and let_value can do same thing, here is the example:

#include <stdexec/execution.hpp>
#include <exec/static_thread_pool.hpp>

#include <cstdio>

namespace ex = stdexec;

int main() {
    // Declare a pool of 8 worker
    threads:exec::static_thread_pool pool(8);
    ex::scheduler auto sch = pool.get_scheduler();
    auto s0 = ex::schedule(sch);
    auto s1 = s0 | ex::then([]() {
        std::printf("sender 1\n");
        return 1000;
    });
    auto s1_ = s1 | ex::split();
    auto s2 = s1_ | ex::then([](int val){
        std::printf("sender 2, val = %d\n", val);
    });
    auto s3 = s1_ | ex::then([](int val){
        std::printf("sender 3, val = %d\n", val);
    });
    auto s4 = ex::when_all(s2, s3);
    ex::sync_wait(s4);
    
    auto let_s4 = s1 | ex::let_value([](const int& val){
        auto s2 = ex::just(val) | ex::then([](int val){
            std::printf("sender 2, val = %d\n", val);
        });
        auto s3 = ex::just(val) | ex::then([](int val){
            std::printf("sender 3, val = %d\n", val);
        });
        return ex::when_all(s2, s3);
    });
    ex::sync_wait(let_s4);
    
}

https://godbolt.org/z/6946G5c5h
Is that right? If yes, when should I use split? when should I use let_value?

[maikel]

Hi,

this is a good question! The effect that you achieve for this particular example is very similar, but the algorithms split and let_value have different purposes.

split

The sender returned by ex::split(std::move(s1)) is always copyable and can be connected multiple times even after it has completed once. But the operation associated with s1 is only started once. If you visualize your senders as a graph, the split algorithm is literally a split that connects one parent node with multiple children. To achieve this, the current implementation

(i) creates a reusable shared state within the sender returned by split
(ii) stores the completion result in the shared state upon the completion of the input operation (once started)
(iii) uses an intrusive list and some thread synchronization primitives (atomic pointers) to notify each connected operation
(iv) passes a const lvalue reference whenever another receiver is connected

Remember, that the input operation is started only once, i.e. you can not even easily use split for repeat-like algorithms, which might require multi-connectable or copyable senders but want to invoke some effect multiple times.

let_value

The sender returned by let_value on the other hand does not need to be copyable. It plays a similar role to co_await for coroutines, i.e. it invokes a continuation function and allows chaining of async operations. But it is missing the language support of coroutines and can lead to nested scopes (let_value in let_value in let_value)

To summarize

(i) The result of the input operation is stored within the operation state of let_value
(ii) passes a non-const lvalue reference to a continuation function, connects the returned sender and starts the resulting second operation.
(iii) The lifetime of the result is maintained until the second operation completes

Let value is one of the bread and butter algorithms that you will find to use regularily with S/R. It is decently cheap.

There are things you can not (easily) do with one or the other algorithm, they are just different algorithms.

[villevoutilainen]

Right. You'll probably notice the differences if you pass data from the sender to its continuations. let_value() sequences a sender onto another, it's a sender-pipeline-chaining operation, and then some, within one pipeline. split() performs a sender-pipeline fork, giving you two pipelines.

[villevoutilainen]

Really? I don't think they can, everything is connected to s1, and by extension s0, which is the scheduler-sender of the thread pool.

[villevoutilainen]

I mean, looks like it's the other way around, the senders produced by the lambdas used with let_value are not associated with the thread pool at all, so they run in the main thread. The ones used with split run in the thread pool, afaics.

[maikel]

In the case of let_value all involved senders complete synchronously after being scheduled on the thread pool. Thats by they are all being invoked on one worker thread.

In the case of split what can happen in the call of when_all is, that the first operation is started and completes before the second operation starts. If the first operation is notified before the second operation even starts then this second operation will complete on the main thread.

It is easier to see if you add multiple sync_waits, here https://godbolt.org/z/7KnrhqoGW

[fililili]

wow, that's amazing. I think it may introduce many bugs in the future. for example: https://godbolt.org/z/P1YfTn1x4

[maikel]

That's why I try to emphasize, that the input sender to split is connected and its operation started only once. Split is not about repeating side effects but about distributing the result of an async computation to multiple recipients whenever it is ready.

Note, that updating a global variable, printing to stdout and so on are side effects.

[villevoutilainen]

Ah, yes, indeed.