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: Roland McGrath <roland at hack dot frob dot com>
- To: Torvald Riegel <triegel at redhat 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: Fri, 8 Apr 2016 11:30:19 -0700 (PDT)
- 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>
> 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?
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.