Re: Adding reentrancy information to safety notes?

["Carlos O'Donell" <carlos@redhat.com>]

On 01/01/2015 02:11 AM, Alexandre Oliva wrote:
> On Dec 31, 2014, "Carlos O'Donell" <carlos@redhat.com> 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.

> I.e., stack traces such as:
> 
>   foo
>   bar
>   foo
>   [...]
>   <signal>
>   [...no foo...]
>   main
> 
> should be just as safe as:
> 
>   foo
>   bar
>   foo
>   [...no foo...]
>   main
> 
> 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?

I guess you can prove it by assuring that you're only calling AS-safe
functions, of which foo isn't one of them, and if it is, then it's
safe to call anyway.

How would you rewrite the original definition to include this case?

Cheers,
Carlos.