Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in let_value(sndr, fun) use sndr's completion scheduler as current scheduler for sender returned from fun #32

Open
ericniebler opened this issue Dec 7, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@ericniebler
Copy link
Collaborator

Issue by ericniebler
Wednesday Sep 13, 2023 at 16:28 GMT
Originally opened as brycelelbach/wg21_p2300_execution#47


None

@ericniebler ericniebler added the bug Something isn't working label Dec 7, 2023
@lewissbaker
Copy link
Collaborator

I think this change has since been applied to the wording that was merged into the WD with P2300R10, so this issue could probably now be closed.

See [exec.let] p2 (https://eel.is/c++draft/exec.let#2) which defines SCHED-ENV(sch) helper, which produces an environment that has a get_scheduler query that returns the completion scheduler of the predecessor sender. This is then stored in the op-state and moved into receiver2 constructed in p11 / p12.

However, I'm not sure if this is the right design.
If I write on(thread_pool, let_value(some_io_read, [](auto& buf) { return process(buf); })) then it would be surprising to me if the process operation ended up seeing a get_scheduler of the io-scheduler that is the completion scheduler of some_io_read instead of the scheduler that I injected into the context from above.

I think the rules around get_scheduler and get_completion_scheduler are still unclear in terms of exactly what the query represents. e.g. is get_scheduler just referring to an ambient scheduler that should be used for scheduling new work? Or does it represent the scheduler that the operation will be started on? While in many cases these two things will be the same, we are not really clear what the semantic requirements and guarantees of get_scheduler are and thus it's unclear whether behaviour like the one suggested in this issue is desired behaviour or not.

Unfortunately, this issue does not have any justification/rationale behind why this semantic was desired. @ericniebler do you recall what the motivation/use-case was behind making this change?

@ericniebler
Copy link
Collaborator Author

get_scheduler tries to return the scheduler that the work is started on. We don't say that anywhere and we probably should. And it's imperfect because we don't propagate the environment through set_* or start.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants