On Wed, 21 Jun 2023 at 21:32, Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, Jun 21, 2023 at 3:02 PM Smith, Jim via Std-Proposals <std-proposals@lists.isocpp.org> 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 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals