On Wed, 21 Jun 2023 at 21:32, Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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"):
> https://en.cppreference.com/w/cpp/experimental/future/is_ready
> It didn't propose the same feature for `std::thread`, but it easily could
> have.
>
> 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.
>

It's trivial to implement std::future::is_ready() in terms of
std::future::wait_for(0s) but I don't know how to implement a
std::thread::try_join() or std::thread::join_will_not_block() portably. As
Thiago pointed out, the necessary functions for Pthreads are not part of
POSIX (not even the 202x draft).



> 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,
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>