Thread-, Signal- and Cancellation-safety documentation

[Torvald Riegel]

On Mon, 2013-06-10 at 10:10 -0400, Carlos O'Donell wrote:
> On 06/10/2013 03:19 AM, Florian Weimer wrote:
> > On 06/08/2013 05:11 PM, Carlos O'Donell wrote:
> >> 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.
> > 
> > Do you suggest to deliberately make our documentation ambiguous
> > instead, so that we can blame other programmer when we make
> > incompatible changes required by POSIX 8?
> 
> No. 
> 
> We can document what we have implemented and say so,

Agreed.

> but we
> should not develop our own formal definitions

I disagree.  Not because we need our own but because we need *some*
proper definition to be able to explain what we actually mean, without
ambiguities.

> provide 
> guarantees against those definitions.

Agreed that we don't want to provide any non-POSIX guarantees in the
long term.  (I don't want to rule out that there are no such cases, but
that's not essential to this discussion.)

> Which is exactly what Alex is doing by defining mt-safe with
> exceptions, even though this may not be the best solution it
> is a safe and incremental approach.
> 
> > Sorry, but this whole discussion appears increasing surreal to me.
> > Library documentation should be useful to programmers. Certainly,
> > precise documentation combined with a backwards compatibility promise
> > constrains future implementation choices. But without detailed
> > documentation, programmers (and other documentation authors) will
> > guess what the intended interface is, perhaps even consult the source
> > code, and program against an imagined interface.
> 
> I don't disagree with any of your statements.
> 
> I only disagree that today and now is the time to provide a formal
> definition of thread safety to be used as a guarantee for future 
> behaviour.

Would you also disagree that now is the time to provide a formal
definition of thread safety that is not advertised as a guarantee for
future behavior?  That is, a definition that formalizes our
interpretation of thread safety?  If so, why would you disagree?


Torvald