search

cplusplus / sender-receiver

Issues list for P2300
Apache License 2.0
20 stars 4 forks source link

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

Open ericniebler opened 11 months ago

ericniebler commented 11 months ago

Issue by lewissbaker Tuesday Dec 28, 2021 at 23:47 GMT Originally opened as https://github.com/NVIDIA/stdexec/issues/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 commented 11 months ago

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 commented 4 months ago

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 commented 3 months ago

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 commented 1 month ago

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