incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <mse...@gmail.com>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Thu, 06 Sep 2012 23:54:20 GMT
>> 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:

> static void*
> f (void* pv)
> {
>      std::numpunct<char>  const&  fac =
>          *reinterpret_cast<  std::numpunct<char>*>  (pv);
>
>      while (hold) ;
>
>      for (int i = 0; i != MAX_LOOPS; ++i) {

            const std::locale loc ("en_US.utf8");

            typedef std::numpunct<char> NumPunct;
            NumPunct const& fac = std::use_facet<NumPunct>(loc);

>          std::string const grp = fac.grouping ();
>      }
>
>      return 0;
> }
>

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

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';
   }

Martin

Mime
View raw message