This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Adding reentrancy information to safety notes?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Michael Kerrisk <mtk dot manpages at gmail dot com>, Peng Haitao <penght at cn dot fujitsu dot com>, Alexandre Oliva <aoliva at redhat dot com>, "linux-man at vger dot kernel dot org" <linux-man at vger dot kernel dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 30 Dec 2014 10:45:42 -0500
- Subject: Adding reentrancy information to safety notes?
- Authentication-results: sourceware.org; auth=none
Michael, Peng, Alex,
We have had some recent discussions about reetrancy safety
of dlopen. My goal is going to be to ensure that dlopen
and in general the intefaces in libdl remain reetrant to
allow user implemented malloc to use these interfaces to
load libraries that themselves may have reetrant helper
functions.
This raises the question: How do we clearly document which
functions are reetrant?
My thoughts are as follows:
* Add some introductory text about reetrancy in the safety
section. This text will discuss that AS-safe functions
are reetrant because they must be to be AS-safe. Note that
reetrant functions need not be AS-safe nor MT-safe.
* Add a "R-Safe" and "R-Unsafe" to indicate safety with respect
to reetrancy.
* Immediately annotate all AS-safe functions as R-Safe.
* Review all of the "_r" functions for reetrance safety.
Thoughts?
My review of other Unices indicates this is probably the
last type of safety that documented by other systems.
Cheers,
Carlos.