Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.teleman@gmail.com
 designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <504FF10E.8020506@hates.ms>
References: <40394653-8FCC-4D04-A108-2C650AF8F95B@hates.ms>
	<CALdE9OD4RyJFq1Gci00G0ay1L80M-127Tuve9Nvx4NY5GtvKNw@mail.gmail.com>
	<50479CA6.8010306@hates.ms>
	<CALdE9OCx_OLwPhTJGKR7AYSA84ECHfiwru0n_kwUhfg_Sb3Qqw@mail.gmail.com>
	<CALdE9OC0cD6UOZ+DMK5D+51Z02tbt9gv4F8PTwL_zCeR9tn1sA@mail.gmail.com>
	<50481097.2080307@gmail.com>
	<CALdE9OCPSs6pcpMFZ+6rq6O+BXJJ+E-QEC1jDSoOb4xn2FiN=g@mail.gmail.com>
	<50481DDC.6010906@gmail.com>
	<5048A224.7060402@hates.ms>
	<CALdE9OCy=8awBwaE4cc1bGURx=DWX9HQBA4JF-kgY6a+9hEaAg@mail.gmail.com>
	<5048CC76.5060603@gmail.com>
	<CALdE9OCO298AmkwWJcuMkMOG7kym9vqHYwnfh3pA2m5Jf_gqUw@mail.gmail.com>
	<5049016D.8000902@gmail.com>
	<CALdE9OAXm7UsjR+O8TsAHUa6h1cxkiA-mq7YN5asg3Ci2mw4kA@mail.gmail.com>
	<CALdE9ODiPtTK8UYe+rKgfcBf350-WkiNu9LUgE=gM6313JLLYQ@mail.gmail.com>
	<504E2440.1060706@gmail.com>
	<CALdE9OBED+0p+JzkN=Zqk+VSFvj4nv6VN6AE1o7E817CeL7KUQ@mail.gmail.com>
	<CALdE9OBhD8GLeQP8Z5F8Lo8DtxYXfBMAP0ZjQzxqB32YnsnJ4g@mail.gmail.com>
	<504FE7F9.90102@gmail.com>
	<504FF10E.8020506@hates.ms>
Date: Wed, 12 Sep 2012 00:21:49 -0400
Message-ID: 
 <CALdE9OB9XPF6f+nH9S-=9NAE0Fj2D44JmXudD00-BXrk0=bU3w@mail.gmail.com>
Subject: Re: STDCXX-1056 [was: Re: STDCXX forks]
From: Stefan Teleman <stefan.teleman@gmail.com>
To: dev@stdcxx.apache.org
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 11, 2012 at 10:18 PM, Liviu Nicoara <nikkoara@hates.ms> wrote:

> AFAICT, there are two cases to consider:
>
> 1. Using STDCXX locale database initializes the __rw_punct_t data in the
> first, properly synchronized pass through __rw_get_numpunct. All subsequent
> calls use the __rw_punct_t data to construct returned objects.
> 2. Using the C library locales does the same in the first pass, via
> setlocale and localeconv, but setlocale synchronization is via a per-process
> lock. The facet data, once initialized is used just like above.
>
> I probably missed this in the previous conversation, but did you detect a
> race condition in the tests if the facets are simply forwarding to the
> private virtual interface? I.e., did you detect that the facet
> initialization code is unsafe? I think the facet __rw_punct_t data is safely
> initialized in both cases, it's the caching that is done incorrectly.

I originally thought so too, but now I'm having doubts. :-) And I
haven't tracked it down with 100% accuracy yet. I saw today this
comment in src/facet.cpp, line 358:

// a per-process array of facet pointers sufficiently large
// to hold (pointers to) all standard facets for 8 locales
static __rw_facet*  std_facet_buf [__rw_facet::_C_last_type * 8];

this leads me to suspect that there is an upper limit of 8 locales +
their standard facets. If the locales (and their facets) are being
recycled in and out of this 8-limit cache, that would explain the
other thing I also noticed (which also answers your question): yes, i
have gotten the dreaded strcmp(3C) 'Assertion failed' in
22.locale.numpunct.mt when I test implemented 22.locale.numpunct.mt in
a similar way to your tests. which in theory shouldn't happen, but it
did. which means that there's something going on with
behind-the-scenes facet re-initialization that i haven't found yet.
which would partially explain your observation that MT-tests perform
much worse with caching than without.

this is all investigative stuff for tomorrow. :-)

and I agree with Martin that breaking ABI in a minor release is really
not an option. I'm trying to find the best way of making these facets
thread-safe while inflicting the least horrible performance hit.

i will run your tests tomorrow and let you know. :-)

--Stefan

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