>
> Hi Юрий, if you want to stay within the standard, want the resources to be
> freed cleanly and stay within the C++ exception semantics, you have to
> accept potential problems during thread termination: To free arbitrary
> resources, code (inside the destructors) is run. That code can deadlock,
> too. How would you react? The destructors could theoretically throw
> another exception C++ code normally knows, whether exceptions can happen,
> e.g. not in noexcept expressions. How and where would the exception
> throwing be inserted into the program? An interrupt handler does not know
> the current state and instructions of the program. In the end those
> threads probably would have to be compiled in a mode similar to a debug
> build, guaranteeing that the thread can be interrupted at any time (as if
> the user presses the pause button of the debugger).



Yes, of course, I would like to stay in the standard paradigm as much as
possible and, for sure, a number of problems will remain unresolved. This
method is not a silver bullet, but it can help solve some problems. I
consider the forced cancellation of a thread from outside as an exceptional
situation, not a request, but a reality that the thread has encountered.
But it's not really an exception, it shouldn't be caught in catch and
handled, it should just call all destructors. Therefore, this entity is
only conditionally an "exception".
Considering destructors, if we requested a thread to stop while it is in
the destructor, then we should not interrupt the destruction of the object,
we should wait for the destructor to complete and after that start
unwinding the stack. It will be possible to determine whether we are in the
destructor or not by the counter, increment the counter when entering the
destructor prologue, decrement when exiting the epilogue, when it reaches
zero, we begin to unwind the stack. Do the destructors that throw
exceptions conform to RAII or not? It seems this is not always the case. In
order for a destructor throwing an exception to be RAII compliant, it must
release all resources before any exception is thrown. And I think that in
the case when, during stack unwinding, we met a destructor corresponding to
RAII, but that threw an exception, it would be reasonable just to suppress
this exception, release the memory occupied by the object and proceed to
the destruction of the next object.
The problem of a deadlock in the destructor you mentioned before is a
special case that will require a harder stop of the thread, apparently
there will be no ideal solution and something will leak out of the blocked
destructor, but in this case, stopping the thread and calling the rest of
the destructors from the stack will reduce the damage. However, this case
must be detected, for example, a timeout can be used, after which the stack
will begin to unwind even from the destructor.