This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?

On Wed, Oct 02, 2013 at 02:43:37PM -0700, Ian Lance Taylor wrote:
> On Wed, Oct 2, 2013 at 1:50 PM, Rich Felker <> wrote:
> >
> > It depends on what you mean by "portable". There's absolutely nothing
> > useful you can do with a signal handler if writing portable C (since
> > there's not even a portable way to expect a signal to happen).
> I agree with you, but just to be pedantic I'll note that the functions
> raise and signal are both ISO C, and that ISO C permits a signal
> handler to assign a value to a variable of type volatile
> sig_atomic_t.  So I believe that this is a fully conforming ISO C
> program that uses a signal handler.

If you use raise to invoke the signal handler, you can do a lot more
than just that. See C99 paragraph 5:

  "If the signal occurs other than as the result of calling the abort
  or raise function, the behavior is undefined if the signal handler
  refers to any object with static storage duration other than by
  assigning a value to an object declared as volatile sig_atomic_t, or
  the signal handler calls any function in the standard library other
  than the abort function, the _Exit function, or the signal function
  with the first argument equal to the signal number corresponding to
  the signal that caused the invocation of the handler. Furthermore,
  if such a call to the signal function results in a SIG_ERR return,
  the value of errno is indeterminate."

Signal handlers invoked via raise are unrestricted, except that plain
C does not defined the behavior if raise is called reentrantly
(paragraph 4).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]