On Tue, Sep 25, 2012 at 10:58 PM, Martin Sebor <mse...@gmail.com> wrote:
> As for Stefan's patches, the biggest problem I see there > (besides the above) is that they introduce changes that > appear to be unrelated to the problem without providing > a satisfactory rationale. The established stdcxx bug > fixing process is to create as small a patch as possible > that does nothing but address the problem. This is > particularly important when we don't have ready access > to test the patch with all the targeted compilers and > on all the targeted operating systems (to minimize the > risk of incidental breakage and to make it as easy as > possible to root cause possible regressions. There is a very simple rationale for the complexity of the second version of the thread safety patch: you objected to the first version of the patch, the one I had originally submitted for 1056, because it was too coarse. I am talking about the patch which applied the mutex lock to every public interface in std::numpunct<> and std::moneypunct(). This patch is also the absolute simplest one in terms of code changes, and it does not affect binary compatibility at all. The complexity of the second version of the patch is a consequence of your request to try finding a version which is not as coarse, which performs a more granular and shorter-lasting mutex locking, and which preserves binary compatibility. That's what the second patch version does. However, it comes with code complexity side-effects. It is also slightly better than the first one in terms of performance. One of the ways by which this somewhat better performance with more granular locking was achieved was by increasing the size of the locale cache, and by eliminating automatic and unnecessary cache resizing operations, which involve copying and deletions. This change simply eliminates code. A second way by which this was achieved was by unwinding recursion. The usefulness and/or necessity of using recursion in __rw_get_numpunct() and __rw_get_moneypunct() was dubious anyway. Because of the existing design and implementation of the locale caching, there isn't much wiggle room, if preserving binary compatibility is a hard requirement. -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
