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

Relax when_all to allow other stop-token implementations than inplace_stop_token #302

Open
lewissbaker opened this issue Nov 7, 2024 · 2 comments
Labels
design discussion We need to talk about this; there's nothing actionable here yet P0

Comments

@lewissbaker
Copy link
Collaborator

The specification of the when_all algorithm is currently written to require that it passes a receiver to child operations that has an environment with an inplace_stop_token as the result of the get_stop_token() query.

Given the possibility of using finite_inplace_stop_source<N> for when_all as proposed in P3409, we may want to relax the constraint on implementations of when_all to allow them to pass other types of stoppable-tokens to child operations. i.e. by not specifying what stop-token type is produced and instead just describing under what conditions a stop-request is sent to that stop-token.

The question for requirements on when_all is probably something that should be explored further in P3409, but also raises a wider question of how far do we want to constrain implementations with regards to the types they use.

@dietmarkuehl
Copy link
Collaborator

dietmarkuehl commented Nov 7, 2024

What is done for when_all should also be done for split: both explicitly use in_place_stop_source.

@inbal2l inbal2l added the discussion We need to talk about this; there's nothing actionable here yet label Nov 8, 2024
@lewissbaker
Copy link
Collaborator Author

Given that finite_inplace_stop_token was rejected in SG1, we can probably close this as "won't fix".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design discussion We need to talk about this; there's nothing actionable here yet P0
Projects
None yet
Development

No branches or pull requests

3 participants