This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MTASCsft PATCH WIP5 01/33] Multi Thread, Async Signal and Async Cancel safety documentation: intro
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, libc-alpha at sourceware dot org, mtk dot manpages at gmail dot com
- Date: Tue, 19 Nov 2013 12:19:01 -0500
- Subject: Re: [MTASCsft PATCH WIP5 01/33] Multi Thread, Async Signal and Async Cancel safety documentation: intro
- Authentication-results: sourceware.org; auth=none
- References: <20131113081059 dot 3464 dot 51385 dot stgit at frit dot home> <20131113081132 dot 3464 dot 30409 dot stgit at frit dot home> <Pine dot LNX dot 4 dot 64 dot 1311131256090 dot 18987 at digraph dot polyomino dot org dot uk> <528A77D4 dot 2090802 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311182306540 dot 8831 at digraph dot polyomino dot org dot uk>
On 11/18/2013 06:11 PM, Joseph S. Myers wrote:
> On Mon, 18 Nov 2013, Carlos O'Donell wrote:
>
>> On 11/13/2013 07:57 AM, Joseph S. Myers wrote:
>>> On Wed, 13 Nov 2013, Alexandre Oliva wrote:
>>>
>>>> +@item @code{simfpu}
>>>> +@cindex simfpu
>>>> +
>>>> +Functions annotated with @code{simfpu} may misbehave on powerpc ports in
>>>> +which the floating-point unit is disabled and floating point simulation
>>>
>>> Reviewing <https://sourceware.org/ml/libc-alpha/2013-11/msg00189.html>,
>>> and <https://sourceware.org/ml/libc-alpha/2013-11/msg00180.html> on which
>>> it depends, would be better than documenting the bug....
>>
>> The adverb better should be associated with some kind of improvement
>> e.g. better that we have less defects instead of more detailed documentation.
>>
>> While I agree that it is always better from a quality perspective to fix
>> bugs instead of documenting them, the problem is that Alex's goal here is
>> not to fix the bugs but to document several attributes for all functions
>> in the library.
>
> When considering a patch that we know is not the right solution to
> something and parts of which are likely to need reverting as part of the
> right solution, I think the relevant consideration is how soon that
> reversion is likely to be needed.
>
> In this case, the proper solution already exists and so the reversion is
> likely to be needed soon. That is very different from the async signal
> safe TLS patches, which could well largely be made obsolete by a proper
> fix for bug 16134 (ensuring TLS allocation failure results in
> pthread_create or dlopen failure) but where there is no indication of
> anyone currently working on such a fix.
Point well made, but it's still open ended as to when you'll get the
patched committed into trunk. I don't want to presume that you'll do
this on any timeline, this is your time and your work.
Adhemerval just reviewed it this morning, and you've checked this in so
Alex now needs to remove the caveat about this.
Cheers,
Carlos.