Re: [gtk-list] recursive gtk_main() calls and garbage collection

[owt1 cornell edu]

On Sat, 8 Nov 1997, Tim Janik wrote:

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

I have trouble being terribly bothered about this.

- I don't think people really do this type of stuff much. (I haven't
  seen a single example in working on quite a wide range of free 
  software). By  the time you're doing such things, you've 
   a) Made porting your program rather difficult
   b) Made adding threading close to impossible.
  You probably should just use a better language than C. ;-)

But, more importantly:

- Although there is no constraint on what happens within a recursive
  gtk_main(), gtk_main() will only be called recursively when the application
  specifically asks for it. So if you're doing such dangererous 
  non-reentrant things, don't call gtk_main() recursively. (Or do
  so in a safe place - often you want to do this in a signal handler
  that is called from gtk_main - so as long as avoid your alloca()
  in the signal handler, you should be OK)

Anyways, you can already have signal handlers called from 
recursive gtk_main's now which could cause the same problems. (Maybe
you're more likely to want to do garbage collection in an idle
function, but the problem exists either way.) My patch just makes
recursive gtk_main's work better.

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

If this (figuring out if gtk_main is recursive or not) is something 
people need, it would be very easy to do. (Just add a global "runlevel"
variable that is incremented when gtk_main is called, and decremented
when it left.

Regards,
                                       Owen

P.S. - I would encourage people to test out my mainloop patch

 (http://www.msc.cornell.edu/~otaylor/gtk-gimp/patches.html)

Everything that it was possible to do before should work exactly
as before, or there's a bug. I'd like to get it out of my hands, but 
first I want to make sure that it doesn't break anything. I suspect GUBI 
in particular is probably a good stress test from what I've seen. If I 
don't hear any negative reports in the next week or so, I'll assume it 
works fine, and commit it to CVS.