> 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals