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: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Rich Felker <dalias at libc dot org>, 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, 7 Jan 2015 10:52:55 +0100
- 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> <orppb0dur7 dot fsf at livre dot home> <54A41F36 dot 5010800 at redhat dot com>
- Reply-to: mtk dot manpages at gmail dot com
On Wed, Dec 31, 2014 at 5:07 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 12/31/2014 04:38 AM, Alexandre Oliva wrote:
>> On Dec 31, 2014, "Carlos O'Donell" <carlos@redhat.com> wrote:
>>
>>> That is not the definition of reentrancy that I had in mind.
>>
>> Since reentrant is such an overloaded term, how about using the term
>> Recursion-Safe, that AFAICT covers only the concept you have in mind.
>> Another possible term that occurs to me is Synchronously Reentrant, to
>> indicate it doesn't cover asynchronous reentrancy out of signals or
>> multiple threads. We could then shorten it as SR-Safe.
>
> Michael,
>
> Any suggestion for an alternate term?
>From what I've seen of the discussion, and not having thought about it
at great depth, Synchronously Reentrant + SR-Safe sound okay to me.
Cheers,
Michael
> Alex,
>
> In hindsight I see that reetrancy is an overloaded term.
> The POSIX standard uses "reentrant by signals" to mean AS-Safe.
> Several authors seem to use "reetrant by another thread"
> to mean MT-safe. Thus without some kind of qualifier the term
> reentrant seems ambiguous at best.
>
> You suggest "synchronously reentrant", and that might be the
> best and most flexible definition. You have to define at what
> points the function might be synchronously reentered, much like
> synchronous cancellation defines such points. In the case of
> glibc internals you can be synchronously reentered only if you
> call a function that might directly or indirectly call malloc,
> calloc, realloc, or free. AFAIK these are the only functions
> that allow users to synchronously interrupt glibc internal
> operations and call back into the runtime. Application calls
> to core runtime functions may be interposed and in those cases
> the interposing function must follow the standard requirements,
> but for maximum compatibility may need to adhere to the
> preliminary safety notes along with the new SR notes.
>
> Note that synchronously reetrant would still follow the
> definition I gave in the previous email. Restated here with
> some slight rewording:
> ~~~~
> A function is synchronously reentrant if a 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 an
> asynchronous signal or by another thread.
> ~~~~
>
> I amended the definition to say "asynchronous signal" since
> it is possible for user code to synchronously handle signals
> and that such synchronous signal handlers could make effective
> use of SR-safe functions since such handlers would be known
> not to be asynchronously interrupting any such previous calls
> to the SR-safe functions. Similarly synchronous cancellation
> handlers should be able to call SR-safe functions?
>
> Cheers,
> Carlos.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/