Returns the depth of the stack of calls to
MainContext.dispatch on any glib.MainContext in the current thread.
That is, when called from the toplevel, it gives 0. When
called from within a callback from MainContext.iteration
(or MainLoop.run, etc.) it returns 1. When called from within
a callback to a recursive call to MainContext.iteration,
it returns 2. And so forth.
This function is useful in a situation like the following:
Imagine an extremely simple "garbage collected" system.
This works from an application, however, if you want to do the same
thing from a library, it gets more difficult, since you no longer
control the main loop. You might think you can simply use an idle
function to make the call to free_allocated_memory(), but that
doesn't work, since the idle function could be called from a
recursive callback. This can be fixed by using g_main_depth()
There is a temptation to use g_main_depth() to solve
problems with reentrancy. For instance, while waiting for data
to be received from the network in response to a menu item,
the menu item might be selected again. It might seem that
one could make the menu item's callback return immediately
and do nothing if g_main_depth() returns a value greater than 1.
However, this should be avoided since the user then sees selecting
the menu item do nothing. Furthermore, you'll find yourself adding
these checks all over your code, since there are doubtless many,
many things that the user could do. Instead, you can use the
following techniques:
1. Use Widget.setSensitive or modal dialogs to prevent
the user from interacting with elements while the main
loop is recursing.
2. Avoid main loop recursion in situations where you can't handle
arbitrary callbacks. Instead, structure your code so that you
simply return to the main loop and then get called again when
there is more work to do.
Returns the depth of the stack of calls to MainContext.dispatch on any glib.MainContext in the current thread. That is, when called from the toplevel, it gives 0. When called from within a callback from MainContext.iteration (or MainLoop.run, etc.) it returns 1. When called from within a callback to a recursive call to MainContext.iteration, it returns 2. And so forth.
This function is useful in a situation like the following: Imagine an extremely simple "garbage collected" system.
This works from an application, however, if you want to do the same thing from a library, it gets more difficult, since you no longer control the main loop. You might think you can simply use an idle function to make the call to free_allocated_memory(), but that doesn't work, since the idle function could be called from a recursive callback. This can be fixed by using g_main_depth()
There is a temptation to use g_main_depth() to solve problems with reentrancy. For instance, while waiting for data to be received from the network in response to a menu item, the menu item might be selected again. It might seem that one could make the menu item's callback return immediately and do nothing if g_main_depth() returns a value greater than 1. However, this should be avoided since the user then sees selecting the menu item do nothing. Furthermore, you'll find yourself adding these checks all over your code, since there are doubtless many, many things that the user could do. Instead, you can use the following techniques:
1. Use Widget.setSensitive or modal dialogs to prevent the user from interacting with elements while the main loop is recursing.
2. Avoid main loop recursion in situations where you can't handle arbitrary callbacks. Instead, structure your code so that you simply return to the main loop and then get called again when there is more work to do.