On 12/31/2014 04:38 AM, Alexandre Oliva wrote: > On Dec 31, 2014, "Carlos O'Donell" <carlos@xxxxxxxxxx> 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? 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. -- 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
