This is the mail archive of the
mailing list for the glibc project.
Re: Should pthread_kill be marked __THROW?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 4 Apr 2016 14:32:56 -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> <56ED6263 dot 7060406 at redhat dot com>
> pthread_kill is specified as calling the signal handler synchronously if
> it used to send a signal to the current thread.
Also true of kill, sigqueue, and raise.
> With FUSE, even functions such as fstat can result into a callback from
> the kernel to the current process,
The issue only arises if it's a callback defined in the same translation
unit as the call (to fstat or whatever), according to the GCC manual.
In the general case, a FUSE callback could indeed be in the same TU in
the same process as the call. But let's be precise in what we're saying.
> I think the decision to mark all __THROW functions as leaf functions was
> a mistake. Leaf functions are an exception, even among __TRHOW functions.
I'm not sure I believe that. Can you elaborate?
The meaning of "leaf" relevant here is the one documented by GCC for
__attribute__ ((leaf)), which is a definition that covers many more
situations than does the common parlance of "leaf function" (a function
that does not call other functions).
Can you give an example of a function that it's safe to mark with
throw () but it's not safe to mark with __attribute__ ((leaf))?
>From what I can see off hand, the mistake was to mark so many things
with __THROW. Making __THROW imply __attribute__ ((leaf)) was probably OK.