Re: [v3] __pool_alloc rework

[Dhruv Matani <dhruvbird at gmx dot net>]

On Sun, 2004-06-20 at 02:29, Carlo Wood wrote:
> On Sat, Jun 19, 2004 at 08:42:50PM +0200, Paolo Carlini wrote:
> > Carlo Wood wrote:
> > Before any other technical discussion, why don't you give mt_alloc a try?
> > You can find the last version both in mainline and 3_4-branch, just pass
> > --enable-libstdcxx-allocator=mt at build time. If I understand well your
> > problems there are good chances that it can do better than pool_alloc.
> 
> I cannot test it at the moment - but I looked at the code, and it
> looks good: this code does not lock a mutex while calling new
> if I see it correctly.  That would mean that I can use the allocator
> recursively from malloc() (called from operator new).

Ah! Now I understand fully why you wanted to test for whether the
*current* thread held the lock or not!

> It does use a __gthread_key_t however, which might caused problems for me.
> I'd have to test that.  There won't be the need for an accessor that
> tests if the allocator has its mutex locked however.
> 
> Great :).  Will this be included as default in 3.5?
-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

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