Nesting GTK main loops



Can anyone suggest _why_ you'd ever want to nest GTK main loops?

I know that GtkDialogs do it as a mechanism to make getting the "result"
of the dialog back in a programmatic way, but I also gather that they
had to go to some trouble to make that behave.

I worked up some small programs and learned about the how things play
out; interesting to see that starting a new main loop does not prevent
events being handled on windows started by the first main loop... you
just see the your signal handler callback function (the one which starts
new main loops) piling up on the call stack.

What I'm not clear on is whether the original main loop is blocked (I
believe so; after all the callback hasn't returned) and what the
implications of that are with another main loop running (maybe that
downstream signal handlers for the original signal are blocked from
being reached, but otherwise, no effect?).

Since inner main loops don't prevent things from being re-entered in
what is, in effect, a recursive way, the ability to enter nested main
loops seems a recipe for confusion. Is there something obvious I'm
missing?

Cheers all,

AfC
Sydney

-- 
Andrew Frederick Cowie

Technology strategy, managing change, establishing procedures,
and executing successful upgrades to mission critical business
infrastructure.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]