Re: glib: alloca brain damages
- From: Kenneth Albanowski <kjahds kjahds com>
- To: Jeff Garzik <jgarzik pobox com>
- cc: gtk-devel-list redhat com
- Subject: Re: glib: alloca brain damages
- Date: Fri, 8 Jan 1999 20:42:04 -0500 (EST)
On Fri, 8 Jan 1999, Jeff Garzik wrote:
> Thought about this a bit when I was putting in the alloca macros.
>
> The 'sane' module includes a copy of a garbage-collecting alloca, where
> you have to manually call alloca(0) every now and then. I think this is
> the standard alloca replacement people use (but haven't search yet for
> others).
That certainly sounds like it.
> It is tough to tune, but calling alloca(0) for every Nth call to g_free
> or g_malloc may be one way to relieve the app programmer of doing it.
> Only broken platforms will have to do this, thankfully.
It looks like the code can be improved to make the alloca(0) call a little
bit cheaper if nothing has been allocated recently. However, bear in mind
that alloca(0) won't necessarily clean up everything. If you do this:
for (;;) {
void * foo = alloca(10);
// stuff
alloca(0);
}
you'll never dip above the stack level that foo was allocated at, and none
of these blocks will be removed until alloca() is invoked from outside
this loop. Likewise, if we pretend that each scope becomes a stack frame,
then this code:
for (;;) {
{
void * foo = alloca(10);
// stuff
}
{
void * bar = alloca(0);
}
}
won't free anything either, because the stack level doesn't appear to be
different. So just executing alloca(0) every now and then isn't a panacea,
especially in the nested environments common to event loops.
If must support alloca(), I'd suggest a macro "cleanup alloca" that either
expands to alloca(0) or nothing, and the author is expected to pepper
their code with the cleanup call in useful places.
--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]