How to do Iteration and Observation?

[ryobg]

Merry Christmas everyone! 🎄

It’s Xmas morning, and after a long night, the first thing on my mind this morning was… std::execution (yes, I know 🤓). I’ve been digging around and pondering a couple of questions, but haven’t found enough crumbs to piece this together yet. Maybe someone here has some insights:

1. Iterating over a graph of senders: Once I’ve built a nice graph of senders, how would I go about iterating over it? Say I want to attach some metadata to a node (e.g., a taskflow’s .name(), or Dot print) or explore it in other ways—what’s the best approach here?

2. Observing/instrumenting the flow: How might one go about observing the flow within? For example, I’d love to instrument or observe transitions like connect, set_value, set_error, and set_stopped. Any ideas or patterns you’ve used for this?

Would love to hear your thoughts, hacks, or musings on these!

[maikel]

Hi,

I will give you quick answer from my mobile as I don’t know when I will be able to answer you in more detail.

1. lazy customisation via a receivers domain is the closest thing here. Please have a look in Eric’s paper about customisation

2. there is something like a tap(_error,_stopped) algorithm (not standardised) that applies an observing function on each respective completion channel. It’s easy to implement much easier than the then algorithm. I plan to make a tutorial on how to implement that in „user land“ over christmas. I think you might find references to this in something like rx.js

Merry Christmas,
Maikel

[ryobg]

Hi Maik,

1. Are you referring to the P2300 paper? I saw in chapter 5 related topics, but I have hard time to see how the query function can be used to iterate over all nested senders. For example, I don't see then algo ever using one.
2. I suppose, by tap_ that would be something like akin to implement a custom sender which has to be inserted everywhere you need one? On connection, it may create a receiver which just process the error/value/stopped channels, and even the connect back propagation event. This might do.

[maikel]

1. I mean https://wg21.link/p2999 especially recursive sender transformations. Note, p2300 is part of the current draft and not anymore actively worked on. There are many follow-up papers in flight. See https://wg21.link/draft
2. yes I will post you an impl asap

[ryobg]

Thanks for the links and don't bother with the tab_. It looks straightforward, though I wouldn't mind know-how on the conformance with std::execution.

[ryobg]

P.S. I think I'm getting the idea of p2999 in the context of iterations. transform_sender can be customized to accept any kind of senders and thus keep a record of the linking. However, I see a flaw - one can't just take a bundle of wrappers and inspect it, the inspection has to be done at the point(s) of construction | connecting, in a modified environment.

I suppose, I find more intuitive an approach where a custom tagged query is propagating backward, inside the wrapped senders, and thus handling the response to the one who does the query. This can be only in the scope of the query, and is non-intrusive as well. Something along the lines of:

struct sender_t {
    template<typename Tag>
    void query (Tag) {
        customization_point (Tag {}, this);
        wrapped_sender.query (Tag {})...;
    }
};

Now, this may look stupid, and redundant with some other functionality, but I haven't seen one, nor I see it how it can be done with the transform_sender(), outside construction | connecting.