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 glib.global.mainDepth
There is a temptation to use glib.global.mainDepth 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 glib.global.mainDepth 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 gtk.widget.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 glib.main_context.MainContext.dispatch on any #GMainContext in the current thread. That is, when called from the toplevel, it gives 0. When called from within a callback from glib.main_context.MainContext.iteration (or glib.main_loop.MainLoop.run, etc.) it returns 1. When called from within a callback to a recursive call to glib.main_context.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 glib.global.mainDepth
gpointer allocate_memory (gsize size) { FreeListBlock *block = g_new (FreeListBlock, 1); block->mem = g_malloc (size); block->depth = g_main_depth (); free_list = g_list_prepend (free_list, block); return block->mem; } void free_allocated_memory (void) { GList *l; int depth = g_main_depth (); for (l = free_list; l; ); { GList *next = l->next; FreeListBlock *block = l->data; if (block->depth > depth) { g_free (block->mem); g_free (block); free_list = g_list_delete_link (free_list, l); } l = next; } }There is a temptation to use glib.global.mainDepth 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 glib.global.mainDepth 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 gtk.widget.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.