Thread-, Signal- and Cancellation-safety documentation

[Florian Weimer]

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?

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.

For example, the claim that there is no memory barrier implied by 
passing a byte down a pipe is most unsettling.

> The consequence of an incompatibility with POSIX is so terrible
> that what you argue is too risky a path to take.

On the other hand, if we don't document interface guarantees which are 
implicitly required by applications programs today, this will weaken our 
position (and force us to eventually adopt changes which are de facto 
backwards-incompatible) in the POSIX 8 standardization, won't it?

-- 
Florian Weimer / Red Hat Product Security Team