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

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 26, 2013, "Joseph S. Myers" <joseph@codesourcery.com> wrote:

> I don't know any good reason for __sim_* to have public GLIBC_* symbol 
> versions, but at present they do.

I'm pretty sure it was a mistake.

> 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).

Yup.

> 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.

But then, can functions whose side effects may have to be reverted if
called within a signal handler be regarded as AS-safe?  That the
standard marks these states as indeterminate gives us some leeway in
documenting functions as safe even when non-conforming uses could
trigger problems (very much like the rationale for fclose's
thread-safety, based on undefined behavior rules), but should we use
this indeterminacy to disregard the (un?)expected ill effects that an
async signal that modifies but does not restore state could bring about?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer