This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consensus on MT-, AS- and AC-Safety docs.

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

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

That doesn't mean we can't start talking about it though,
and I've started a document here:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]