C++ Logo


Advanced search

Re: [std-proposals] Make std::thread not joinable after thread function ends.

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Wed, 21 Jun 2023 16:32:01 -0400
On Wed, Jun 21, 2023 at 3:02 PM Smith, Jim via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Yes, actually proposing a non-blocking join() that returns true or false
> because if join() returns false, the thread is not running.
> Need a way to say if(thread_is_running) { ... }, and must keep existing
> logic already in code so future or promise isn't allowed.
> The below is closer to what I intended.
> >>> If(t.join_will_notblock()) t.join();

Ah. That has nothing to do with `t.joinable()`. But it is a potentially
useful property.
The Concurrency TS proposed to add exactly this feature to `std::future`,
under the name `f.is_ready()` (meaning no more or less than "`f.wait()`
won't block"):
It didn't propose the same feature for `std::thread`, but it easily could

Anyway, `std::future` kind of died before the Concurrency TS could rescue
it. But it wouldn't be a terrible proposal to resurrect just the
`.is_ready()` getters on `future` and `thread` — and anything else that
might benefit from that kind of getter. As Lee said, there's no
implementation difficulty here, and no data race.

Counterargument: The more common C++ library idiom is
`.try_lock()`/`.try_acquire()`, which would lead instead to `f.try_get()`
and `t.try_join()`. But I doubt that "try" semantics are useful in these
cases (especially for `try_join`).

my $.02,

Received on 2023-06-21 20:32:15