Re: Should pthread_kill be marked __THROW?

[Roland McGrath <roland at hack dot frob 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.


Thanks,
Roland