This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 26 Mar 2013 20:06:53 +0000
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home>
On Tue, 26 Mar 2013, Alexandre Oliva wrote:
> Another issue that came up was using/changing the floating point
> control/status word. It seems that all ports that support floating
> point exceptions, rounding modes, etc, use hardware floating point, with
> thread-specific FP registers holding the control&status info, and having
> these registers preserved by the signal machinery just like all other
> registers. Unfortunately, this is not the case of powerpc fpu
> emulation: it uses a global variable (which makes a number of functions
> mt-unsafe) that's not restored when signal handlers return control to
> the interrupted function (which makes them as-unsafe), but I documented
> them as safe anyway, because I regard the current behavior as a bug that
> ought to be fixed.
I don't know any good reason for __sim_* to have public GLIBC_* symbol
versions, but at present they do. Thus, to fix the thread-safety issue
those existing symbols (for global variables) would probably be made
compat symbols for any existing binaries, and new TLS symbols (under
different names) at GLIBC_PRIVATE would be used within the code, except
that it would update both the compat global variable and the TLS variable
(but only ever read the TLS variable).
That wouldn't give signal safety as you describe it, but C11 explicitly
makes floating-point state indeterminate in a signal handler, and
indeterminate after a signal handler if the handler changes it and doesn't
restore the state as it was on entry. So I think this version with TLS
variables would be valid according to C11.
--
Joseph S. Myers
joseph@codesourcery.com