Re: Should pthread_kill be marked __THROW?

[Florian Weimer <fweimer at redhat dot com>]

On 03/18/2016 11:35 PM, Roland McGrath wrote:
> I don't really understand the rationale by which you think pthread_kill (or
> anything else) should be any sort of barrier if it isn't clearly specified
> in POSIX (or appropriate standard for something else) that it must be one.

pthread_kill is specified as calling the signal handler synchronously if
it used to send a signal to the current thread.

Even without that, GCC still generates incorrect code if there is *any*
way to prove that the callback has run because with the leaf attribute,
the code assumes that no user code runs, and (for example) static
variables are not reloaded.

> Whatever conclusion applies to pthread_kill should also apply to kill,
> sigqueue, killpg, gsignal, and possibly raise.

With FUSE, even functions such as fstat can result into a callback from
the kernel to the current process, which means that anything accessing
the file system cannot really be labeled as a leaf function.

For malloc & friends, we have official (but deprecated) replacement
hooks, yet the functions are marked __THROW.  malloc interposition is
another official sanctioned callback mechanism.  No function which
touches the heap can be considered a leaf function as a result.

Similarly, the networking functions in libresolv call a user-supplied
callback, yet they are marked __THROW.  (Even without the callback, the
__THROW attribute is probably what caused problems with some of my
resolver tests because the queries are sent to the same process.)

The most blatant misuse of the __THROW attribute is probably exit, which
calls the exit handlers.

I think the decision to mark all __THROW functions as leaf functions was
a mistake.  Leaf functions are an exception, even among __TRHOW functions.

Florian