[execution.senders.adaptors.bulk] Should clarify that bulk customisations are allowed to decay-copy 'args' if required

[ericniebler]

Issue by lewissbaker
Tuesday Dec 28, 2021 at 23:47 GMT
Originally opened as NVIDIA/stdexec#341

---

The current wording indicates that when the input sender sends args that customisations of bulk must invoke f(i, args...) for each i in 0..shape.

However, if the customisation of bulk wants to execute f on some other context it will need to be done asynchronously and thus the implementation will need to decay-copy args to some temporary storage in the operation-state so that they are still available when f is to be invoked.

Should the wording be made explicit here that f is allowed to be invoked with a decay-copied version of args... instead of the same args... that were passed to set_value()?
If so, should the bulk operation be required to complete with a pack of values with the same value category as the predecessor completed with, or is completing with xvalues referencing the decay-copied versions an acceptable transformation of the value-channel for bulk implementations that need to decay-copy the args?

Also, should we be explicit that f is invoked with lvalue references to args... or the decay-copied args...?
If so, are customisations required to pass the same lvalues to each invocation of f?`
If so can we clarify that in the wording too?

[ericniebler]

Comment by lewissbaker
Tuesday Dec 28, 2021 at 23:50 GMT

---

Also, we need to add a requirement that customisations must complete with set_value(out_r, args...).
And also that if s completes with set_error or set_done that this result is forwarded through as the result of the bulk operation and that f is not invoked.

[lewissbaker]

The current wording of bulk in P2300R10 seems to only require that the function, f, satisfies movable-value. This means that the implementation of bulk cannot guarantee that the decay-copied f can actually be copied to different execution-agent-local storage.

Is the intent that only a single f instance is invoked from multiple execution-agents?
i.e. are customisations allowed to copy f if it is copyable? This would be observable if it does.
or are customizations required to always invoke the same f instance?

It seems like we need to be clearer in the wording about what we want to allow here.

[lucteo]

And also that if s completes with set_error or set_done that this result is forwarded through as the result of the bulk operation and that f is not invoked.

I don't think this is feasible. bulk may invoke f several times before it encounters an error/stopped condition and it's forced to complete with set_error/set_stopped.

[inbal2l]

Issue is addressed in: "P3481: Summarizing std::execution::bulk() issues" (Lewis Baker, Lucian Radu Teodorescu, Ruslan Arutyunyan)