This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Rich Felker <dalias at aerifal dot cx>, Torvald Riegel <triegel at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 29 Nov 2013 17:59:07 -0500
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <528A7C8F dot 8060805 at redhat dot com>
On 11/18/2013 03:46 PM, Carlos O'Donell wrote:
> Having said all this, do any of you object in any way to the
> addition of this documentation?
I appreciate everyone's input here, thank you all for
contributing.
I wanted to bring this discussion back around to consensus and
summarize some points made by Joseph, Torvald, Rich, Ondrej,
Florian and others.
Please look over (1), (2), (3), (4), and (5), and object if
you see something where you feel we don't have consensus.
Please start a distinct thread for each objection. If you
object to multiple items on one thread I will split that
discussion into multiple threads. I want us to work through
one item at a time until there is consensus for that point
and then move forward.
(1) Preliminary documentation.
We need to make it clear that we are documenting a preliminary
set of notes on all the functions and their safety.
To that end the consensus is to add "Preliminary:" to the
safety documentation that is going with each function.
(2) Cross references.
We want to provide cross references from the safety notes
to their actual definitions.
(3) Exception keywords.
It seems to be consensus that English exception keywords
are the preference. The list of new keywords as proposed
by Alex is:
Current Proposed Numbering (see below)
staticbuf race
lockleak lock
selfdeadlock lock
asynconsist corrupt
incansist corrupt
asmalloc malloc
asi18n i18n
shlimb dlopen
uplugin plugin
oncesafe init
1stcall init
uunguard const
xguargs race
tempchwd cwd
tempsig sig
tempterm term
stimer timer
glocale locale
envromt env
fdleak fd
memleak leak
unposix posix
IIUC we have consensus on these keywords.
(5) MT-Safe definition is driven from the standards down.
Consensus, despite some dissenting, is that the more accurate
definition of MT-safe must comes down from the standards
first before we re-review our code and documentation.
Torvald I am recording for the record that you have raised
your objection again to the use of MT-Safe without providing
a formal definition of safe that can be used to reason about
larger problems.
This is the second time you have raised this concern, the
first being when we started the project. I acknowledge that
this is a serious issue, but that it will not be addressed
by this work.
At present POSIX has no memory model, and no strict definition
of safe. Therefore this documentation project will not be
adopting any more complex definition of safe other than what
is in POSIX or roughly:
~~~
MT-Safe functions are safe to call in the presence of
other threads, i.e., that will behave as documented
regardless of what other threads are doing, as long as
they all refrain from invoking undefined behavior.
~~~
We previously agreed that the definition of MT-safe must
come down through the standards. POSIX must have a logical
definition of MT-safe before glibc adopts that logical
definition.
That doesn't mean we can't start talking about it though,
and I've started a document here:
https://sourceware.org/glibc/wiki/Multi-threaded%20safety
Please start a distinct thread to discuss this document
and it's refinement to allow glibc to eventually express
a full definition of MT-Safe. That work should be presently
orthogonal to the work of documenting against the current
loose POSIX definition.
I know you don't like this, but it is the way that it is.
We need to drive this from the standards down, and for this
first documentation pass it is not feasible to apply a more
complex definition of MT-Safe.
Cheers,
Carlos.