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: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Rich Felker <dalias at aerifal dot cx>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 10 Jun 2013 19:24:06 +0200
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx> <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> <51B5DE64 dot 10304 at redhat dot com>
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