This is the mail archive of the
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 <firstname.lastname@example.org> 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 18.104.22.168 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