Date: Thu, 22 Jun 2023 03:06:53 +0300
On Thu, 22 Jun 2023 at 02:56, Lee Howes via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> Jonathan's concerns are more fundamental. We can always achieve this by setting a flag at the end of the thread's main function if we really want to. So thread could be wrapped in a thread class that wraps the function and sets a completion flag, which can be read by the is_ready function. It's bad enough that we now have thread and jthread, queryable_completion_thread just adds options to choose between.
Perhaps we shouldn't create such a standardized package, then, and
users should just wrap their thread-function into a wrapper function
that
sets such a flag, and read it however they like. Packaging the storage
and initialization of that flag with the thread plus an API for
reading
the flag shouldn't be rocket science either. If that ends up being an
incredibly common thing to do, we can then entertain standardizing
such
a package.
<std-proposals_at_[hidden]> wrote:
> Jonathan's concerns are more fundamental. We can always achieve this by setting a flag at the end of the thread's main function if we really want to. So thread could be wrapped in a thread class that wraps the function and sets a completion flag, which can be read by the is_ready function. It's bad enough that we now have thread and jthread, queryable_completion_thread just adds options to choose between.
Perhaps we shouldn't create such a standardized package, then, and
users should just wrap their thread-function into a wrapper function
that
sets such a flag, and read it however they like. Packaging the storage
and initialization of that flag with the thread plus an API for
reading
the flag shouldn't be rocket science either. If that ends up being an
incredibly common thing to do, we can then entertain standardizing
such
a package.
Received on 2023-06-22 00:07:07