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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Michael Kerrisk <mtk dot manpages at gmail 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: Mon, 05 Jan 2015 10:26:47 -0500
- 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> <or8uhndlfm dot fsf at livre dot home>
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.