Re: Thread-, Signal- and Cancellation-safety documentation

["Joseph S. Myers" <joseph at codesourcery dot com>]

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