This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding reentrancy information to safety notes?

On Wed, Dec 31, 2014 at 5:07 PM, Carlos O'Donell <> wrote:
> On 12/31/2014 04:38 AM, Alexandre Oliva wrote:
>> On Dec 31, 2014, "Carlos O'Donell" <> 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.



> 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;
Linux/UNIX System Programming Training:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]