stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <nikko...@hates.ms>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Fri, 07 Sep 2012 11:37:17 GMT
On 09/06/12 19:54, Martin Sebor wrote:
>>> I'm not sure how easily we can do that. Almost all of locale
>>> is initialized lazily. Some of the layers might depend on the
>>> facets being initialized lazily as well. This was a deliberate
>>> design choice. One of the constraints was to avoid dynamic
>>> initialization or allocation at startup. [...]
>>
>> There would be a performance degradation. IMHO, it would be minor and would simplify
the code considerably.
>>
>> After finally being able to reproduce the defect with SunPro 12.3 on x86_64 I tried
to remove the lazy initialization and a (smaller) test case now passes. I am attaching the
program and the numpunct patch.
>
> Out of curiosity, does it still work if you move the locale into
> the thread function? Like this:

I created the test case because I wanted something more specific and with more predictable
results. Initially, the locale object was created in the thread and it was passing.

>
>
> Also, does the 27.objects test pass with this patch?

Will try. I don't think that we can actually use this patch, I bundled it with the test so
that people can test the approach right away.

>
> I don't know if we have tests for it but writing to cerr/cout
> in a bad_alloc handler should succeed. I.e., this should not
> abort:
>
>    try {
>        struct rlimit rlim = { };
>        getrlimit (RLIMIT_DATA, &rlim);
>        rlim.rlim_cur = 0;
>        setrlimit (RLIMIT_DATA, &rlim);
>
>        for ( ; ; ) new int;
>    }
>    catch (bad_alloc) {
>        cout << "caught bad alloc: << 123 << '\n';
>    }

I see..

Liviu


Mime
View raw message