stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <stefan.tele...@gmail.com>
Subject Re: STDCXX-1056 : numpunct fix
Date Fri, 21 Sep 2012 09:13:31 GMT
On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
<Travis.Vitek@roguewave.com> wrote:

> You called out premature optimization as evil, in a discussion about patches you provided
that include optimizations and no testcase showing that your changes are not premature and
provide measureable benefit. Then you rail on...

I didn't call premature optimization evil. Donald Knuth did. If you
disagree with him, please feel free to let him know. He's on faculty
at Stanford.

> Then, to top it off, you go on to call me a know-it-all who isn't capable of figuring
out my own bugs.
>
> I'm sorry, but that isn't acceptable

Too bad if you feel that way. Next time you get the idea of making
snide remarks about my working knowledge of the Standard C Library, or
offer out-of-context one-line code fragments completely unrelated to
what this 1056 bug is about, maybe you'll think twice. And this isn't
the first time you offer gratuitous snide remarks directed at me.

You are one of the deniers of the existence of this thread safety
problem in the facets code, going back to early February of this year.

Between the release of stdcxx 4.2.1 in 2008 and the beginning of this
month, when the possibility of this thread safety problem was finally
acknowledged, did you really not know that 22.locale.numpunct.mt and
22.locale.moneypunct.mt have been crashing or getting stuck? Did you
really not know that these crashes were typical symptoms of race
conditions? I find that very hard to believe, given that the problem
has been reported several times before February of this year.

I have provided this list with test results showing that my patch
*does* fix the race condition problems identified by all the tools at
my disposal. I'm willing to bet you never looked at it. You dismissed
it outright, just because you didn't like the *idea* that increasing
the size of the cache, and eliminating that useless cache resizing
would play an important role in eliminating the race conditions.

I have yet to see an alternative patch being proposed here, which
would eliminate the race conditions, and which I am willing to test
just as thoroughly as I've tested mine. The only thing i've seen are
continued attempts at dismissing the existence of these race
conditions, as  reported by the instrumentation tools, based on some
general axioms about their accuracy. No-one on this list has a clue as
to how the SunPro Thread Analyzer actually works, because it's not
open source, and none of you work at Oracle, therefore you can't see
the code. But everyone just *knows* that it's inaccurate, or that it
reports false positives.

As long as you, or anyone else, continues to blame the instrumentation
tools for the bug, and as long as anyone here continues to suggest
that the only acceptable proof of the existence of this bug is some
other program which needs to be written using fprintf(3C), and as long
as no-one here is willing to provide an alternative patch which
demonstrably eliminates 100% of the reported race conditions, this
entire back-and-forth about the existence of these race conditions,
the accuracy of the tools and what they are reporting is nothing but a
giant waste of time.

-- 
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com

Mime
View raw message