> -----Original Message-----
> From: Stefan Teleman [mailto:stefan.tele...@gmail.com]
> Sent: Friday, September 21, 2012 2:14 AM
> To: dev@stdcxx.apache.org
> Subject: Re: STDCXX-1056 : numpunct fix
> On Fri, Sep 21, 2012 at 2:28 AM, Travis Vitek
> <travis.vi...@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.

I never said I disagree with the Knuth quote. I just said you have to apply it 
consistently. Is your change an optimization or not? If it is, then is it a 
premature optimization? Do we have a test case (or test results) to indicate 
that there is a discernible performance improvement?

> 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.

Again from my previous e-mail.

I don't think anyone is claiming that there isn't a thread safety problem in 
the locales. I'm open to the possibility, and I'm willing to review changes 
that fix the problem, but I want some understanding of what the problem 
actually is and how the changes actually address the problem before signing off.

> 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 looked at every line of your proposed patch _before_ my last e-mail. Despite 
the fact that you didn't provide it in the expected format (diff) and it 
included many changes that are unrelated and make little sense.

> 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....

I'm _not_ denying the existence of the problem. Please re-read all of my 
correspondence on this issue. If you don't believe me after that, re-read it 

Reply via email to