This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: Rich Felker <dalias at aerifal dot cx>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, GNU C Library <libc-alpha at sourceware dot org>, Andrew Hunter <ahh at google dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Wed, 2 Oct 2013 18:08:21 -0400
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <CALoOobPJ7G7ciRfc2JwzHjsDTg4-_h-SXqeU1zR4WEzoyQhyNg at mail dot gmail dot com> <523BD470 dot 6090203 at redhat dot com> <CAKOQZ8y85QBkd97cEEmP-4OgE2KizCqknrVR_n44pwBGMs5uAw at mail dot gmail dot com> <523C88D1 dot 6090304 at redhat dot com> <20130920175246 dot GE20515 at brightrain dot aerifal dot cx> <1380705404 dot 8757 dot 1847 dot camel at triegel dot csb> <20131002205046 dot GT20515 at brightrain dot aerifal dot cx> <CAKOQZ8z3WkhMQ1FqQgxuEJJq8TqHtzZkA-1x=02D0UQA2di82g at mail dot gmail dot com>
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 <dalias@aerifal.cx> 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 7.14.1.1 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).
Rich