On Thu, Sep 20, 2012 at 8:44 PM, "C. Bergström" <cbergst...@pathscale.com> wrote:
> > fencepost comment - The results are based on tools and I don't think he has > a large program which actually triggers the conditions. (Creating one may > take quite some time....) I do have a program which triggers the race conditions: 22.locale.numpunct.mt. Part of the "official" test harness. The real reason why they don't want to accept what the instrumentation tools are saying is very simple: they don't LIKE reading what the tools are saying. So, blame the tools, pretend that "as long as it doesn't crash again there's no bug" and hope for the best. Who knows, maybe it won't crash. Maybe it will. Doesn't matter, right? The official fprintf(3C) debugger says it's thread-safe, so it must be. Quite frankly, I am *dismayed* that fprintf(3C) is considered an acceptable method of debugging thread-safety problems. You are correct: I did not, and will not, waste my time writing *any* program which attempts to debug thread-safety problems with fprintf(3C). But I am very glad this is on a public mailing list, so everyone can read what's going on here. -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
