search

NVIDIA / stdexec

`std::execution`, the proposed C++ framework for asynchronous and parallel programming.
Apache License 2.0
1.56k stars 159 forks source link

in_place_stop_token::stop_possible has inconsistent semantics #417

Closed hkaiser closed 1 year ago

hkaiser commented 2 years ago

The semantics of in_place_stop_token::stop_possible differ from those of std::stop_token::stop_possible.

in_place_stop_token::stop_possible:

Returns: source_ != nullptr && source_->stop_possible().

std::stop_token::stop_possible (see: http://eel.is/c++draft/thread.stoptoken#stoptoken.mem-2):

 Returns: false if:
 - *this does not have ownership of a stop state, or
 - a stop request was not made and there are no associated stop_­source objects; otherwise, true.

This leads to different return values after request_stop() was called on the associated source object.

ericniebler commented 2 years ago

This leads to different return values after request_stop() was called on the associated source object.

How so?

hkaiser commented 2 years ago

This leads to different return values after request_stop() was called on the associated source object.

How so?

As mentioned in https://github.com/brycelelbach/wg21_p2300_std_execution/issues/416, after request_stop() was called, in_place_stop_token::stop_possible() always returns false, while stop_token::stop_possible() may still return true.