On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely via Libstdc++
<libstd...@gcc.gnu.org> wrote:
> After resolving a PEBKAC issue, here's an incremental diff that
> preserves the old behaviour for the existing @GLIBCXX_3.4.11 symbol,
> but adds a new @@GLIBCXX_3.4.30 symbol that supports cancellation via
> __forced_unwind.
>
> Maybe we should also do this in the implementation of the old noexcept
> function:
>
> __attribute__((used))
> void
> __nothrow_wait_cv::wait(std::unique_lock<std::mutex>& lock) noexcept
> {
> int old;
> int err = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old);
> this->condition_variable::wait(lock);
> if (!err && old != PTHREAD_CANCEL_DISABLE)
> pthread_setcancelstate(old, &old);
> }
>
> This would prevent cancellation from terminating a process if it uses
> the old symbol. So we'd have a new symbol that supports cancellation,
> and an old one that safely disables it.
That sounds good to me.
Also, I'm not sure it was pointed out, for the original: changing a
noexcept function to start throwing can leak exceptions
through other noexcept functions, hitting catch-blocks instead of
terminates, or terminates that occur much later
than intended. The compiler will assume that it doesn't need to set up
the LSDA in a noexcept function if everything
you call is noexcept, and then you don't have the LSDA that would
terminate right then and there. That's probably
a lesser problem for the thread cancellation exception than it would
be for some others, but it's a blood-curdling/chilling possibility
that we should just avoid. And you have done that, thanks for that.
