Re: Adding reentrancy information to safety notes?

[Rich Felker <dalias at libc dot org>]

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