Re: [Boost-users] [system] local static and threading in C++03

Subject: Re: [Boost-users] [system] local static and threading in C++03
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-12-30 18:45:53

Le 31/12/12 00:15, Felipe Magno de Almeida a écrit :
> On Sun, Dec 30, 2012 at 3:39 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> Le 27/12/12 21:32, Felipe Magno de Almeida a écrit :
> [snip]
>
>>> Also, I was expecting race conditions to be taken more seriously than
>>> to wait for
>>> bad behavior to appear. It is, afterall, a correctness issue.
>> You are right. the issue should be taken in account.
>>
>> Does the following schema extracted from Boost.Units solve the issue or it
>> works only for POD types?
>>
>> namespace detail {
>>
>> template<bool>
>> struct xalloc_key_holder
>> {
>>      static int value;
>>      static bool initialized;
>> };
>>
>> template<bool b>
>> int xalloc_key_holder<b>::value = 0;
>>
>> template<bool b>
>> bool xalloc_key_holder<b>::initialized = 0;
>>
>> struct xalloc_key_initializer_t
>> {
>>      xalloc_key_initializer_t()
>>      {
>>          if (!xalloc_key_holder<true>::initialized)
>>          {
>>              xalloc_key_holder<true>::value = std::ios_base::xalloc();
>>              xalloc_key_holder<true>::initialized = true;
>>          }
>>      }
>> };
>>
>> namespace /**/ {
>>
>> xalloc_key_initializer_t xalloc_key_initializer;
>>
>> } // namespace
>>
>> } // namespace detail
>>
>> /// returns flags controlling output.
>> inline long get_flags(std::ios_base& ios, long mask)
>> {
>>      return(ios.iword(detail::xalloc_key_holder<true>::value) & mask);
>>
>> }
> I might not be knowledgeable enough to comment, but this seem a very
> strange hack for the initialization order fiasco.
I don't know if it is a hack, but is been used in Boost in a lot of 
libraries.
>
> [snip]
>
>>>> Boost.System will depend on Boost.Thread and Boost.Thread already depends
>>>> on
>>>> Boost.System.
>>> I see. I rather they be interdependent than to have race conditions.
>>> And I don't think call_once
>>> requires boost.system. So at least cyclic includes could be avoided.
>>>
>> Yes, but this will mean to have two Boost.Thread libraries boost_thread
>> (with call_once) and boost_futures (which depend on Boost.System). I'm not
>> against this but this will mean a new breaking change.
> If call_once were made header-only, there wouldn't be any breakage. IIUC.
>
>
I let you and Beman (Boost.System author) to continue this discussion. 
Please, create a Trac ticket for Boost.thread if some modifications are 
needed.

Best,
Vicente