On Jan 5, 2015, "Carlos O'Donell" <carlos@xxxxxxxxxx> wrote: > On 01/01/2015 02:11 AM, Alexandre Oliva wrote: >> On Dec 31, 2014, "Carlos O'Donell" <carlos@xxxxxxxxxx> wrote: >> >>> 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'd qualify the asynchronous signal to state that it need not be safe >> only if the signal interrupted asynchronously the execution of the >> previous call, otherwise it would also allow a(n indirectly) recursive >> function, called from the signal handler for the first time, to be >> unsafe when called recursively. > That is true. I considered this in the context of synchronous signal > delivery but couldn't come up with a real way to assure myself that > the signal didn't interrupt foo. >> but it's ok if foo is unsafe here: >> >> foo >> bar >> [...] >> <signal> >> [...] >> foo >> [...] > I agree that this can happen. The question I have is: Is it worth > allowing this if you can't prove that foo wasn't being executed? Well... I guess an application that implements a function and sets up a signal handler that might call it could always arrange for the function to test some property very early in its execution, and unset just before the end of its execution, so that the signal handler can tell whether it is safe to call such an SR-Safe but AS-Unsafe function, or whether it has to take some other path. > How would you rewrite the original definition to include this case? 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 by another thread, or while handling an asynchronous signal that interrupts the execution of the function. Here's another somewhat more formal definition, that defines invocations rather than functions as (a)synchronously reentrant, and defines SR-Safe as a property equivalent to the definition above: An invocation of a function F is a direct part of an execution of a function G iff G calls F, or G accepts a synchronous signal whose handler is F. The execution of function G may encompass other direct parts that are not function invocations. An indirect part of an execution of a function F is any direct part of the execution of a function G, whose invocation is in turn a direct or indirect part of the execution of F. An invocation of a function F is synchronously reentrant iff it is a direct or indirect part of another execution of F. An invocation of a function F is asynchronously reentrant iff it occurs in one thread while another thread carries out a direct or indirect part of an execution of F, or in an asynchronous signal handler that interrupted any direct or indirect part of another execution of F. A function F is SR-Safe iff it is safe for any direct or indirect part of an execution of F to be a synchronously reentrant invocation of F, absent any asynchronously reentrant invocation of F. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- 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