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: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 10 Jun 2013 05:27:15 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <CAHGf_=q=2sM0C5kLazsVWiRfRvO0NX-sDRX2-SfoJkkCix9vzQ at mail dot gmail dot com> <1368788825 dot 3054 dot 3182 dot camel at triegel dot csb> <ora9nrh1cz dot fsf at livre dot home> <1369592301 dot 16968 dot 3046 dot camel at triegel dot csb> <orehcoqm0d dot fsf at livre dot home> <1370363818 dot 16968 dot 11024 dot camel at triegel dot csb> <orsj0ur1nu dot fsf at livre dot home> <1370610034 dot 16968 dot 11295 dot camel at triegel dot csb> <51B349B4 dot 7050304 at redhat dot com> <51B57DF0 dot 9090107 at redhat dot com>
On Mon, Jun 10, 2013 at 09:19:12AM +0200, 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?
I think the possibility that it might be incompatible with Issue 8 is
a good reason FOR writing this document. If Issue 8 imposes a memory
model that's incompatible with glibc's current behavior, all the
research that went into such a document will be critical for bringing
glibc into conformance. If, on the other hand, Issue 8 aims for very
weak synchronization like I would expect, the document will simply
remain a (very useful) part of the documentation of glibc and the
synchronization properties it guarantees on top of the bare minimum
POSIX requires.
> For example, the claim that there is no memory barrier implied by
> passing a byte down a pipe is most unsettling.
I agree it's unsettling, but that's part of the value of this
discussion. I think it's pretty clear that, as written, the standard
does not require any memory barrier here, but all historical
implementations provide one, and historical applications depend on it.
So we are at a point where, if the barrier is deemed important, it's
not too late to try to amend the standard to require one.
> >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?
I agree. Implementors having this kind of discussion and rigorous
documentation is critical to the standards-writing process.
Rich