This is the mail archive of the
mailing list for the glibc project.
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: Mon, 18 Nov 2013 15:46:07 -0500
- Subject: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
Joseph, Torvald, Rich,
The three of you have made long or brief comments on the work
that Alex has posted on the mailing list titled:
"MT-, AS- and AC-Safety docs."
The work itself is a detailed code review with the goal to
document multi-threaded safety, asynchronous-signal safety,
and asynchronous-cancellation safety in the glibc manual (the
canonical place for such documentation).
The documentation adds the safety information along with
exception information. The exceptions are broken down into
groups and reflect the implementation realities and limitations
We have already set aside the discussion that the multi-threaded
guarantees we provide are insufficient to help users answer all
of the questions they might have about their program's behaviour.
That discussion has changed scope and the goal there is going to
be to have the upstream POSIX language changed. Torvald, that's
something that you, and I and other interested parties can do.
The desire to fix bugs as we find them is strong. We are all
interested in the well being of the project, but to stop the
documentation effort in mid-swing is to loose momentum. Therefore
Alex has been filing bugs as he finds them instead of fixing them.
Some bugs run deep and some functions will need to be rewritten to
be MT-safe, and that's a lot of work. Remember the goal here is
documentation. Once the documentation is done we can do a bug
fixing pass with the knowledge of everything in the library that
is potentially broken.
Having said all this, do any of you object in any way to the
addition of this documentation?
My goal is to start reviewing this work in earnest to get it
added to the manual for 2.19.