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

[Torvald Riegel <triegel at redhat dot com>]

On Sat, 2013-06-08 at 11:11 -0400, Carlos O'Donell wrote:
> On 06/07/2013 09:00 AM, Torvald Riegel wrote:
> >> First of all, it's not clear that we're talking about current or future
> >> standards.
> > 
> > If we have a deficiency in the current standard, that presumably needs
> > to be fixed, then we can do that now in what we provide to users, with
> > the hope of later applying it to a future version of the standard.  I
> > don't see any problem here.
> 
> No. There is a big problem here.
> 
> The complexity of the topic is so high that a mistake on our part
> could have us document something that is later incompatible with
> Issue 8 of POSIX.

I agree that there might be such a risk -- but only if we're not clear
in how we attribute our definitions.  If we do the following, do you
still see the risk?:

1) (Let's assume that) the current POSIX definition is too vague, so we
need to at least come up with a complete definition of how we interpret
the Posix requirements.

2) We clarify that our interpretation could be different than what POSIX
intends; it's an interpretation, out of necessity.

3) For all deviations that we currently have from the standard, whether
intended or not, we come up with proper classification / definitions.
We make it clear that this documents the current state, but that
complying with POSIX is the only guarantee we make.

Thus, the key point here is making clear how *we* interpret POSIX (and
that we do *interpret*), and that this is *our* interpretation.  If we
can take care of this, I don't see a risk.  I do agree that there might
be people that misunderstand this, but as Florian points out, there are
other sources for such misunderstanding (eg, looking at the source).

> The consequence of an incompatibility with POSIX is so terrible
> that what you argue is too risky a path to take.
> 
> Therefore I am strongly in favour of Alex's position which is to
> use what language POSIX has, even if it not well defined, and to
> improve the documentation.

I agree that we can't be incompatible with POSIX.  But we do not
increase the risk if we document what we have at the moment as long as
we point out that this documents exactly that.

And just keeing the ambiguity and vague definitions is not a solution.
It gives us the "advantage" that we don't need to stick our head out and
never potentially expose any differences in interpretation, but that is
a false advantage.  It doesn't help our users because they will have to
interpret POSIX, so at least at their end we have an interpretation /
misunderstanding risk.  The better we clarify how we understand POSIX,
the easier it is for users (e.g., to see a difference to their
interpretation).  More information and detail just makes the situation
better in this case, provided we make it crystal clear that our goal is
to comply with POSIX.

> This conversation should still happen. It should be about Issue 8,
> and about what will go into the next version of the standard.
> Understanding the problem from glibc's perspective is incredibly
> important because it will help us align with POSIX and comment
> intelligibly on Issue 8.
> 
> However, at that point it is no longer a discussion about Alex's
> patch or his current work.

If I were a user, I wouldn't know what Alex is actually trying to say
when he marks a function as thread-safe.  To me, that what makes this
discussion relate to Alex' current work.  Maybe I'm a weird user because
I've been looking at concurrent code for too long.  But I believe that
once we have detailed definitions, all the subtleties and the subtle
differences in interpretations will be easier to see.

Torvald