Re: [PATCH] Restore mempools functionality for MemBlob

On 03/30/2011 02:59 PM, Kinkie wrote:

>> * If pools are indeed not initialized (and they would not be during some
>> static allocations), we should not access StrPoolsAttrs at all! There
>> are different initialization stages here, and you have to handle the all
>> of them for the code to work reliably.

> Why? StrPoolAttrs is statically initialized in the same translation
> unit as memAllocString. If memAllocString can be called, it has
> already been initlaized.

The last bit is incorrect, AFAIK.

StrPoolAttrs being static (I actually missed that part due to the
terrible syntax used for its declaration!) guarantees that it will be
either all zeros or initialized when memAllocString() is called. The
code calling memAllocString() does not know anything about StrPoolAttrs
and StrPoolAttrs is not local to memAllocString(), so there is no
guarantee that StrPoolAttrs will be initialized before the first call.

I could not find the exact reference quickly, but the following FAQ
describes the same "static initialization order fiasco" problem, albeit
indirectly:
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14

> In any case, I failed to convince you of the viability of this
> approach. As promised, I'll then implement your suggestion of
> assigning max(pool_size)+1 to early allocations;

I do not insist on the M+1 hack. If others think that the check is not
worth the extra KBs for early allocations, it can go. I am just
presenting what I consider is a viable option so that we can make an
informed decision rather than just removing a useful check as "not needed".

Thank you,

Alex.
Received on Wed Mar 30 2011 - 21:46:25 MDT