> -----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. <quote> 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. </quote> > 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 again.
