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

Subject: Re: [Boost-users] [system] local static and threading in C++03
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2012-12-30 18:15:39

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]

>> I think double-free of allocated memory is quite possible, but I think
>> anything
>> is possible depending on implementation details. I rather not rely on
>> implementation
>> details.
>
> I don't see any allocation there. Boost has a lot of code that depends on
> compiler implementation details.

I might be wrong about allocation and deallocation on most
implementations. I'm not against using
implementation details, but they should be explicit, and ifdef'ed
with a default implementation for other compilers.

>> 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.

[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.

> Best,
> Vicente

Regards,
-- 
Felipe Magno de Almeida