This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Should pthread_kill be marked __THROW?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>
- Date: Sun, 10 Apr 2016 11:03:56 +0200
- Subject: Re: Should pthread_kill be marked __THROW?
- Authentication-results: sourceware.org; auth=none
- References: <56E70876 dot 7070109 at redhat dot com> <20160318223555 dot 091B72C3C60 at topped-with-meat dot com> <1460028958 dot 1991 dot 176 dot camel at localhost dot localdomain> <20160408183019 dot B6C892C3B21 at topped-with-meat dot com>
On Fri, 2016-04-08 at 11:30 -0700, Roland McGrath wrote:
> > I agree. Calling a signal handler synchronously is not a concurrency
> > problem in the sense of synchronization with other threads. The signal
> > handler can be considered concurrency, but then we should rather tell
> > the compiler that pthread_kill is like a raise, or not?
>
> I first read "a raise" as "a call to the 'raise' function", but now I think
> you actually meant "raising a C++ exception". Is that right?
No. I wasn't aware that ...
> Currently pthread_kill, kill{,pg}, sigqueue, and raise are all annotated
> in the same way (with our __THROW macro). All of these have the same
> specified requirement that (in some circumstances) the signal handler run
> "inside" the function.
>
> So raise is marked as never doing a raise. That is the problem being cited.
... this is the problem, and thought that raise would be marked
correctly, and only pthread_kill would lack the marking.