recursive gtk_main() calls and garbage collection

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

hi folks,

someone (Owen?) posted a patch that enabled recursive calls
of gkt_main().
will this invokation call idle handlers?
and if so, is there a way to destinct (inside an idle handler) wether
gtk_main() got called recursivly?

if both answers are no, we will get problems with garbage collectors like so:

gtk_main() calls some sub function(s) that do some
alloca(1234) calls whereas alloca() comes from a clib (or libmalloc)
implementation, because alloca() isn't supported on a compiler basis on our
imaginary system.
now gtk_main() is called recursively within the same function that did the
alloca(), and it invokes an idle handler that does an alloc(0) call (for
garbage collection). after the recursive call our function accesses
the alloca()ed memory and - boom corruption...

as the redrawing stuff relies on idle handlers finally, i assume
idle handlers will get called in recursive gtk_main()s. we therefore
need to have some information like stacking order of gtk_main() calls or so...
otherwise we can't use calls to alloc(0), which will blow up our memory
space, or we need to have yet another handler type that hooks into gtk_main()
but is executed only at the topmost iteration loop.



any answers to this problem?

---
ciaoTJ