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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- 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: Mon, 05 Jan 2015 10:05:56 -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> <20150101001905 dot GU4574 at brightrain dot aerifal dot cx>
On 12/31/2014 07:19 PM, Rich Felker wrote:
> 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.
You are correct. Thank you for the contradicting example.
The correction should read:
"A reentrant function may be AS-safe and MT-unsafe."
Thus the safety note is entirely orthogonal to AS and MT safety.
Cheers,
Carlos.