> I suppose you could do that and then immediately detach() from the
thread. You
can't join() because you don't know how long it'll take between the setting
of
that variable and the thread actually exiting: it could take centuries and
the
point of this function is not to block.

Well, yes, but for all practical purposes it would probably work fine. It
just isn't standardisable.

On Wed, 21 Jun 2023 at 17:48, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wednesday, 21 June 2023 16:56:08 PDT Lee Howes via Std-Proposals 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.
>
> I suppose you could do that and then immediately detach() from the thread.
> You
> can't join() because you don't know how long it'll take between the
> setting of
> that variable and the thread actually exiting: it could take centuries and
> the
> point of this function is not to block.
>
> But as Ville says: if a user wants this, why can't they deploy it
> themselves?
> They should even just start their threads detachedly and only check that
> variable.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>