On Friday, 14 July 2023 06:43:50 PDT Юрий Петренко via Std-Proposals wrote:
> The request to stop may come when a thread is modifying a global object,
> which may be left in an invalid state, affecting the work of all the other
> threads. This problem can be solved by a transactional approach to handling
> such objects, or by adding a flag signaling that a critical part of the
> work is happening and should preferably be allowed to terminate. An
> interrupt handler can ignore such a flag if the stop request is at an
> elevated level.

You've just described POSIX thread cancellations, both synchronous and
asynchronous. There already is a mechanism to advise the runtime that the code
has entered a non-atomic block and must therefore not cancel itself out:
pthread_setcancelstate. It also provides a mechanism to register functionality
to be run at the end of a block in case a cancellation happens inside that
block; pthread_cleanup_push() and pthread_cleanup_pop(). In fact, the push/pop
pair is often implemented *as* RAII inside C++ code.

All good implementations[*] of C and C++ threading already merge the POSIX
thread cancellation functionality with C++ RAII, so that if you cancel a
thread, it starts to unwind the stack and runs any destructors. Moreover,
functions that synchronously test for the cancellation token are marked
noexcept(false) to indicate that they may start to unwind the stack.

Given we have this state of the art, please include it in the discussion of
your paper. There are probably problems in the implementation that need to be
addressed before standardisation. The process should include and possibly
extend the functionality expressed by POSIX thread cancellations, because they
exist and are in use today.

[*] glibc + GCC's libsupc++ as runtime, which probably only means Linux glibc.
That by construction means I claim all other implementations are "not good".

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering