You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 aninplace_stop_token
as the result of theget_stop_token()
query.Given the possibility of using
finite_inplace_stop_source<N>
forwhen_all
as proposed in P3409, we may want to relax the constraint on implementations ofwhen_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.The text was updated successfully, but these errors were encountered: