This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Adding reentrancy information to safety notes?
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Michael Kerrisk <mtk dot manpages at gmail dot com>, Peng Haitao <penght at cn dot fujitsu 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: Wed, 31 Dec 2014 19:19:05 -0500
- Subject: Re: Adding reentrancy information to safety notes?
- Authentication-results: sourceware.org; auth=none
- References: <54A2C8A6 dot 9050100 at redhat dot com> <ork318eoj4 dot fsf at livre dot home> <20141230230529 dot GT4574 at brightrain dot aerifal dot cx> <orfvbwegqg dot fsf at livre dot home> <54A377B8 dot 60802 at redhat dot com>
On Tue, Dec 30, 2014 at 11:12:40PM -0500, Carlos O'Donell wrote:
> That is not the definition of reentrancy that I had in mind.
Indeed. To me, "reentrancy" means the ability to enter the code again
while one or more instances of the same function are already running
in the same thread. In my view this doesn't necessarily include
asynchronous reentrancy unless explicitly stated, and it doesn't have
anything to do with the concept of reentrancy in the obsolete POSIX
2001 that was removed and replaced with "thread safety" in later
editions of POSIX.
> [snip]
>
> > Or are these questions meaningless because this definition is not the
> > one we want to use for Reentrancy?
>
> We already use AS-safe to indicate that a function is safe to reenter
> from a signal handler.
AS-safety means more than that. It means that it's safe to use the
function from a signal handler no matter what function the signal
handler interrupted, and that it's safe to call any standard function
from a signal handler that interrupted the AS-safe function. Note that
the latter part can be vacuously true if AS-safety is achieved by
blocking signals for the duration of the function.
> We already use MT-safe to indicate that a function is safe to reenter
> from another thread.
>
> The only definition of reentrancy I had in mind is that which is derived
> from the original definition of single-threaded program reetrancy, with
> the exclusion of signals.
This agrees with my definition.
> The reason I want to use this definition is to more formally describe
> those functions which are safe to call from a user provided malloc.
> A user provided malloc can be called from almost anywhere in glibc, it
> interrupts core glibc code, it only synchronously interrupts core
> glibc code (when malloc is called), and limiting a user provided malloc
> to AS-safe functions would be punative (though that is what we'll be
> doing in the initial documentation pass).
>
> Definition of reentrancy:
> =========================
> ~~~~
> A function is reentrant if the one thread may safely call
> the function before a previous call to the same function
> by the same thread completes, but need not be safe if the
> second or subsequent calls are made while handling a signal.
> ~~~~
> Safely implies no data loss.
>
> By definition all AS-safe functions are reetrant.
>
> A reetrant function may be AS-unsafe and MT-unsafe.
>
> A reetrant function may be AS-unsafe and MT-safe.
>
> A reetrant function may be AS-safe (makes it reetrant by definition) and MT-unsafe.
No, AS-safe does not imply reentrant. Consider a function that invokes
a callback but blocks signals during its execution. It's vacuously
AS-safe but instead of via a signal handler it can be re-entered via
the callback, and whether such reentrancy is safe is a non-trivial
question.
Rich