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: Fri, 19 Apr 2013 19:34:02 +0000
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <Pine dot LNX dot 4 dot 64 dot 1303262002150 dot 14171 at digraph dot polyomino dot org dot uk> <orppya9j92 dot fsf at livre dot home>
On Thu, 4 Apr 2013, Alexandre Oliva wrote:
> 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.
Well - there is in principle a use for the rounding mode information being
available from libc, to implement FLT_ROUNDS correctly (see GCC bug
30569). But that should probably be provided through a function interface
rather than internal variables.
> > 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
I think such cases illustrate the problems with trying to fit every
function into a few fixed categories - in many cases the safety of a
function needs to be described in more complicated ways than just
"AS-safe" or "not AS-safe".
--
Joseph S. Myers
joseph@codesourcery.com