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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Torvald Riegel <triegel 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 10:10:44 -0400
- 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>
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, but we
should not develop our own formal definitions and provide
guarantees against those definitions.
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.
I'm arguing that that work should be done in POSIX and brought into
glibc.
It's fine to have the conversation today and iron out the issues.
> For example, the claim that there is no memory barrier implied by
> passing a byte down a pipe is most unsettling.
No comment.
>> 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?
It will, but the stated goal of this project is to an ISO C and POSIX
compatible library?
Either we change the goals of the project, which I'm not against,
but that's a serious thing to discuss, or we need to find a way to
stay POSIX compatible?
To reiterate: I'm not against this discussion going forward, it's
important, and it should reach a documented resolution, and that
text of the resolution should be taken to POSIX for inclusion and
the community should work to ensure POSIX matches what we're doing
(to the best of our abilities).
I just don't think we should do that first, and then hope that
POSIX adopts all of our requirements.
Cheers,
Carlos.