Re: glib: alloca brain damages

[Tim Janik <timj gtk org>]

On Fri, 8 Jan 1999, Kenneth Albanowski wrote:

> > 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.

thanx for these comments kenneth, i actually think sopwith is right with
his suggestion to only let glib assure that alloca() is available and let
the programmer use it directly from there on. apart from that, the current
glib macros for alloca allocations are somewhat strange anyways, as their
naming suggest they may be used as normal functions, but in fact they
modify a variable that looks like it is passed by value, and people have to
take additional care to not intermix alloca related macros with function call
construction.
given that these macros were introduced after the feature freeze anyways, plus
the fact that their actuall implementation still seems somewhat dubious, i'd
suggest that we only provide a g_alloca() and a g_alloca_cleanup() macro at
this point and nuke g_strdup_a, g_strndup_a, g_strconcat3_a, g_new_a and
g_new0_a.
we can eventually implement well thought out convenience macros during the
1.3 development line then and don't clutter glib's namespace with
half baked alloca() solutions until then.


[ sorry jeff, i would have liked to raise that opinion prior to you doing
  the actuall implementation, but i actually didn't spend enought thought on
  the whole matter due to me having that damn english flue, and then having
  to switch providers because hamburg.netsurf.de went off the net. ]

> 
> -- 
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
> 

---
ciaoTJ