Rewrite of __default_alloc_template<> (was: recursive mutex?)

[Carlo Wood]

On Fri, Oct 19, 2001 at 05:32:04PM -0500, Loren James Rittle wrote:
> > Does this mean I can not add a recursive mutex to libstdc++ without
> > using Thread Specific Data?  I'd rather solve it differently because
> > it seems to me that getspecific is rather slow.
> 
> I admit that I don't know the optimal way to create a recursive mutex
> abstraction from the non-recursive mutex.  Surely, there is some way
> to structure new code to allow the direct use of a non-recursive
> mutex.  Support for the recursive mutex was put in the standard to
> allow one to wrap old interfaces more easily (according to
> _Programming with POSIX Threads_ but I my experience matches the book).

As you know, I need this to solve the dead-lock problem that occurs
when std::cout (and std::cerr) is used from inside operator new.

However, I ran into this dead-lock in the past because I also used
std::string inside operator new;  I now fixed my library to not use
anything anymore that uses std::alloc, except for the final writing
of debug output to the given ostream.

It now turns out to be *extremely* rare that the dead-lock occurs,
because normally, when one writes to an ostream - memory is allocated
when some buffer needs growing which appears to happen always with
chunks larger than 128 bytes, and thus no locking is attempted by
__default_alloc_template.

Nevertheless I'd like to solve this problem.  Writing to an ostream
(pointer) provided by a user can execute arbitrary code and thus
must be resistant against recursive calls to
__default_alloc_template<true, 0>::allocate(size) with size < 128.

As it turns out, I can only solve this by rewritting __default_alloc_template
completely -- something I am interesting in doing anyway because it seems
to "leak" memory (it never frees memory after allocating it).

Before starting to do this, I'd like to know what are the thoughts
about this.  What are the requirements that are most important to
the people on this list?

At the moment, __default_alloc_template uses malloc() for every allocation
larger than 127 bytes.  Smaller ammounts are allocated in a block of 20 pieces
(or less when that is not available) from a memory pool which only, and
exponential, grows.

I think that the point of __default_alloc_template is that it is FAST
for small allocations.  Next to that it shouldn't waste memory (fragmentation
etc).  Are there any other requirements?

-- 
Carlo Wood <carlo@alinoe.com>