A quick word about the pthreadrope7 fails.

[Dhruv Matani]

On Thu, 2004-10-14 at 23:00, Paolo Carlini wrote:
> Dhruv Matani wrote:
> 
> [snip]
> 
> In the light of recent discussions and events, all of this is absolutely
> obvious.

Ok, after reading them, I infer that there is a problem with the static
dtor ordering within the compiler proper, and it's related to code
generation etc... not in the realms of the standard library? Am I
correct or mistaken?

If that's the case, I should just leave the allocator as it is.
Otherwise I'll just temporarily comment out the dtor for the vector and
everything will be just fine. What do you suggest?


> 
> >Cheap as it may seem, it works at the moment. Does this test fail with
> >any other allocator?
> >
> Of course doesn't, since we are not deleting any memory at destruction.
> 
> While we are at it, I also have something obvious to say ;)
> 
> ---------------------------------------------------------------------
> |   136   |    0    | 4294967295 |      Data-> Space for 32-ints    |
> ---------------------------------------------------------------------
> 
> since in the example the Data is 3 x 4 = 12 bytes forward wrt the address
> returned by ::operator new, of course it can only by aligned 4, bummer!
> 
> If the header (the first 3 items) were longs on 64-bit machines you would
> have the Data aligned 8. And if you want the Data aligned 16, just add a
> long of padding between the bitmaps and the data.
> 
> Paolo.
-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

The price of freedom is responsibility, but it's a bargain, because
freedom is priceless. ~ Hugh Downs