Date: Wed, 12 Oct 2022 11:18:08 -0400
On Wed, Oct 12, 2022 at 10:42 AM Raphael via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> Hi,
>
> the current definition of std::stop_source::stop_possible() [1] states that:
>
>> Returns: true if *this has ownership of a stop state; otherwise, false.
>
>
> and the current definition of std::stop_source::stop_requested() [2] states that:
>
>> Returns: true if *this has ownership of a stop state that has received a stop request; otherwise, false.
>
>
> from these requirements it appears that stop_requested() will never return true if stop_possible() return false, but this is exactly what is required as a post condition of std::stop_source::request_stop() [3], where it says:
>
>> Postconditions: stop_Âpossible() is false or stop_Ârequested() is true.
Did you miss the "or" there? Where's the contradiction?
> The issue here appears to be in the definition of std::stop_source::stop_possible() that should be made equivalent to the definition of std::stop_token::stop_possible() [4], something like:
>
>> Returns: true if *this has ownership of a stop state and a stop request was not made; otherwise, false.
Perhaps you're being too literal about the words here. The question
`stop_possible` is meant to answer is merely whether the `stop_source`
is a valid, useful object. That is, it is an object that can feed
`stop_token`s to request a stop.
It does *not* answer whether such a stop has already been requested.
That is, it does not answer whether `request_stop` will change the
state of the `stop_source` and its attendant tokens.
So this is not a defect; it is intended behavior. If you want to ask
whether the object controls stop tokens *and* has not yet been
stopped, those are two separate questions according to the design.
Probably because the combination of those two aren't terribly
meaningful.
`stop_possible` is a sanity check to see if the object is useful.
`request_stop` is a directive to issue a stop to associated tokens. If
you want to request a stop, a sanity check beforehand might be useful,
but the check is just to see if the object is functional. Request the
stop, and the return value will tell you if your thread is the one
that first requested a stop.
<std-discussion_at_[hidden]> wrote:
>
> Hi,
>
> the current definition of std::stop_source::stop_possible() [1] states that:
>
>> Returns: true if *this has ownership of a stop state; otherwise, false.
>
>
> and the current definition of std::stop_source::stop_requested() [2] states that:
>
>> Returns: true if *this has ownership of a stop state that has received a stop request; otherwise, false.
>
>
> from these requirements it appears that stop_requested() will never return true if stop_possible() return false, but this is exactly what is required as a post condition of std::stop_source::request_stop() [3], where it says:
>
>> Postconditions: stop_Âpossible() is false or stop_Ârequested() is true.
Did you miss the "or" there? Where's the contradiction?
> The issue here appears to be in the definition of std::stop_source::stop_possible() that should be made equivalent to the definition of std::stop_token::stop_possible() [4], something like:
>
>> Returns: true if *this has ownership of a stop state and a stop request was not made; otherwise, false.
Perhaps you're being too literal about the words here. The question
`stop_possible` is meant to answer is merely whether the `stop_source`
is a valid, useful object. That is, it is an object that can feed
`stop_token`s to request a stop.
It does *not* answer whether such a stop has already been requested.
That is, it does not answer whether `request_stop` will change the
state of the `stop_source` and its attendant tokens.
So this is not a defect; it is intended behavior. If you want to ask
whether the object controls stop tokens *and* has not yet been
stopped, those are two separate questions according to the design.
Probably because the combination of those two aren't terribly
meaningful.
`stop_possible` is a sanity check to see if the object is useful.
`request_stop` is a directive to issue a stop to associated tokens. If
you want to request a stop, a sanity check beforehand might be useful,
but the check is just to see if the object is functional. Request the
stop, and the return value will tell you if your thread is the one
that first requested a stop.
Received on 2022-10-12 15:19:34