On Wed, Jun 21, 2023 at 8:16 PM Lee Howes via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Yes, exactly. Easily done, and yet another option seems excessive.
>

Well, right, I definitely wouldn't want to see a third "std::xthread"
alongside std::thread and std::jthread. That would definitely be terrible.
Instead, what I was picturing is that the ready-flag could be added
directly to std::thread. Jonathan's comment simply indicates that adding it
would be an ABI break at worst.

But it also occurs to me that std::thread already carries a list of "things
to do when the thread exits," in order to support
https://en.cppreference.com/w/cpp/thread/notify_all_at_thread_exit
https://en.cppreference.com/w/cpp/thread/packaged_task/make_ready_at_thread_exit
https://en.cppreference.com/w/cpp/thread/promise/set_value_at_thread_exit
https://en.cppreference.com/w/cpp/thread/promise/set_exception_at_thread_exit
etc.
So:
(1) could that list somehow be exploited to find out if the thread was
ready, without an ABI break at all? E.g. initialize the list with one dummy
element, and then have `.is_ready()` just check whether the list is empty
right now.
(2) could `notify_all_at_thread_exit` be used somehow to emulate/polyfill
this feature? but I suppose we already know how to emulate it by wrapping
the whole thread in a lambda...
(3) ...except that it wouldn't surprise me if there's a way to run
arbitrarily large amounts of code at thread exit! Either through some very
clever abuse of the standard facilities listed above (which I think have
been designed with the intent of never blocking), or through some pthreads
facility. In which case the approach in (2) would actually be insufficient,
because you could finish the thread's actual work, return from the lambda,
set your "ready" flag, get ready to exit the thread for real... and then
suddenly have an arbitrarily large amount of code to run before the thread
has actually exited (so during that arbitrarily long time your "ready" flag
is lying).

my $.02,
–Arthur