Yes, "throwing an exception into someone else's call-stack" is a good
model. "throwing an exception into someone else's call-stack with trigger
condition" is a more accurate model. I wrote recently "there are certain
intervals at which we can/can't destroy it". Of course, a programmer should
be able to mark such unsafe intervals with a flag. While we are in an
unsafe section, we execute the program code normally, as soon as we leave
the unsafe section we throw an exception. The second condition that checks
our "exception with a trigger condition" is the thread stopping policy. If
an immediate, unsafe stop is requested from outside, it will happen like
that, some resources will leak (if we got into a dangerous place from the
point of view of leaks), but not all of them and this is still better than
TerminateThread.

сб, 15 июл. 2023 г. в 16:40, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]>:

> On Sat, Jul 15, 2023 at 9:27 AM Yuri Petrenko via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > It's great that Linux already has something to rely on, but there is a
> subtle difference. In the case you mentioned, as far as I understand,
> pthread_cancel will ask the thread to cancel, and this will be possible
> only when we reach the Cancelation point, this mechanism is much better
> than a stop token, but very similar to it. In case of RAII thread we can
> interrupt the execution thread immediately without waiting for Cancelation
> point or token check, except for a few intervals like prologue and
> epilogue, destructor (destructors need to be discussed in detail), etc.,
> where special handling is needed.
> > In case of pthread there are points at which we cancel the thread, in
> case of RAII thread there are certain intervals at which we can/can't
> destroy it. The gist of this idea is that if the thread corresponds to RAII
> as a whole, it is not necessary to wait for Cancellation point.
>
> Is it though? Is it really?
>
> Even code that follows RAII principles religiously will have places
> where cancellation at various points will cause breakage. I'm going to
> model your cancellation feature as "throwing an exception into someone
> else's call-stack".
>
> Consider `make_unique`. Somewhere in this function is code that
> reduces down to this:
>
> unique_ptr<T>(new T(...));
>
> In the evaluation of that expression, there is a point where `new T()`
> has been executed but *not* the constructor of `unique_ptr`. Until
> that constructor has finished executing, the pointer is not owned by
> anyone.
>
> However, this is fine. `unique_ptr`;s constructor is `noexcept`, the
> initialization of its parameters are all `noexcept`, and if the `new`
> expression throws, there is no pointer to manage. So between a
> successful evaluation of `new T` and the completion of `unique_ptr`'s
> constructor, no exceptions can possibly be thrown. Therefore, this
> code is exception-safe.
>
> If you can cancel a thread (throw an exception into the call-stack) at
> any point, then you could cancel it at the precise point where no
> exceptions could have otherwise been thrown. That's... bad.
>
> Code can be exception-safe, but that's only because there are places
> where it is guaranteed that no exceptions can be thrown. Cancellation
> *must* work the same way: there must be places where you *cannot*
> cancel a thread. RAII can encapsulate those into constructors and
> functions returning prvalues, but that just puts the uncancellable
> code inside of specific blocks. It still exists and still must be
> uncancellable.
>
> > In general, I would really like to use the handler mechanism you
> mentioned. I'll be sure to add the relevant part to the discussion, thank
> you.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>