public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Ville Voutilainen <ville.voutilainen@gmail.com>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	 "Jonathan Wakely via Libstdc++" <libstdc++@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]
Date: Wed, 8 Dec 2021 18:14:41 +0000	[thread overview]
Message-ID: <CACb0b4=HHZNOJhxOcU-jiogCQObpvv50Mg2a8ZSiWd43pBonSg@mail.gmail.com> (raw)
In-Reply-To: <CAFk2RUbwHf9DdC6zAyLaybaJh-uWpPSifh=BRyu0_jxs=2UQrA@mail.gmail.com>

On Wed, 8 Dec 2021 at 17:36, Ville Voutilainen wrote:
>
> On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely via Libstdc++
> <libstdc++@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.

I think I'll disable cancellation as a separate change, because it's
not what the existing symbol does, and we should look at doing it
anywhere else that will currently terminate.

> 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.

Yes, and those kind of problems are probably more likely in practice,
because the compiler *always* treated that function as noexcept. Users
probably didn't care whether it was or not (and it isn't guaranteed to
be by the standard) so wouldn't have gone out of their way to write
code that depended on it being noexcept.


  reply	other threads:[~2021-12-08 18:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07 20:58 Jonathan Wakely
2021-12-07 21:18 ` Florian Weimer
2021-12-07 21:38   ` Jonathan Wakely
2021-12-07 21:52     ` Florian Weimer
2021-12-08  0:36       ` Jonathan Wakely
2021-12-08 17:26         ` Jonathan Wakely
2021-12-08 17:36           ` Ville Voutilainen
2021-12-08 18:14             ` Jonathan Wakely [this message]
2021-12-09 23:30           ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACb0b4=HHZNOJhxOcU-jiogCQObpvv50Mg2a8ZSiWd43pBonSg@mail.gmail.com' \
    --to=jwakely@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=ville.voutilainen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).