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 -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
