This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] __pool_alloc rework
On Thu, Jun 24, 2004 at 01:45:03PM -0500, Loren James Rittle wrote:
>
> > I hope you will use mt_alloc instead. If pool_alloc is "fixed" in this
> > way then I will have to hack access to 128 different locks - and even
>
> I'm afraid to ask but... Why is one writing any code, anywhere that
> knows the number of library internal locks?
For my "C++ Debugging Support library", libcwd.
In order to avoid a dead lock when writing real-time debug output
to an ostream (any; libcwd is proud to have ostream orientated debug
output) at the moment an allocation is done. The allocation can
be done from libstdc++ in order to increase the size of a memory
pool, this might be the same memory pool that is used when writing to
that ostream (ie, std::cout) - it can happen that exactly at that moment
a buffer is too small, needs more memory and deadlocks because the memory
pool is already locked. Imho, a solution for this problem would
be to not call 'new' from the pool allocator at the moment a lock
is set (mt_alloc does this: it does not lock anything at the moment
it calls operator new). Unfortunately, __pool_alloc does set a lock
and then starts calling happily operator new :/. In order to avoid
this deadlock I had to hack access to the lock of __pool_alloc and
divert (queue) the output when it is locked - this happens SELDOM
and really don't want to start to queue by default.
--
Carlo Wood <carlo@alinoe.com>