Re: STDCXX-1056 [was: Re: STDCXX forks]

[Martin Sebor]

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