Acquires context and sets it as the thread-default context for the
current thread. This will cause certain asynchronous operations
(such as most giogio-based I/O) which are
started in this thread to run under context and deliver their
results to its main loop, rather than running under the global
default context in the main thread. Note that calling this function
changes the context returned by MainContext.getThreadDefault,
not the one returned by MainContext.default, so it does not affect
the context used by functions like Idle.add.
Normally you would call this function shortly after creating a new
thread, passing it a glib.MainContext which will be run by a
glib.MainLoop in that thread, to set a new default context for all
async operations in that thread. In this case you may not need to
ever call MainContext.popThreadDefault, assuming you want the
new glib.MainContext to be the default for the whole lifecycle of the
thread.
If you don't have control over how the new thread was created (e.g.
in the new thread isn't newly created, or if the thread life
cycle is managed by a glib.ThreadPool), it is always suggested to wrap
the logic that needs to use the new glib.MainContext inside a
MainContext.pushThreadDefault / MainContext.popThreadDefault
pair, otherwise threads that are re-used will end up never explicitly
releasing the glib.MainContext reference they hold.
In some cases you may want to schedule a single operation in a
non-default context, or temporarily use a non-default context in
the main thread. In that case, you can wrap the call to the
asynchronous operation inside a
MainContext.pushThreadDefault /
MainContext.popThreadDefault pair, but it is up to you to
ensure that no other asynchronous operations accidentally get
started while the non-default context is active.
Beware that libraries that predate this function may not correctly
handle being used from a thread with a thread-default context. Eg,
see g_file_supports_thread_contexts().
Acquires context and sets it as the thread-default context for the current thread. This will cause certain asynchronous operations (such as most giogio-based I/O) which are started in this thread to run under context and deliver their results to its main loop, rather than running under the global default context in the main thread. Note that calling this function changes the context returned by MainContext.getThreadDefault, not the one returned by MainContext.default, so it does not affect the context used by functions like Idle.add.
Normally you would call this function shortly after creating a new thread, passing it a glib.MainContext which will be run by a glib.MainLoop in that thread, to set a new default context for all async operations in that thread. In this case you may not need to ever call MainContext.popThreadDefault, assuming you want the new glib.MainContext to be the default for the whole lifecycle of the thread.
If you don't have control over how the new thread was created (e.g. in the new thread isn't newly created, or if the thread life cycle is managed by a glib.ThreadPool), it is always suggested to wrap the logic that needs to use the new glib.MainContext inside a MainContext.pushThreadDefault / MainContext.popThreadDefault pair, otherwise threads that are re-used will end up never explicitly releasing the glib.MainContext reference they hold.
In some cases you may want to schedule a single operation in a non-default context, or temporarily use a non-default context in the main thread. In that case, you can wrap the call to the asynchronous operation inside a MainContext.pushThreadDefault / MainContext.popThreadDefault pair, but it is up to you to ensure that no other asynchronous operations accidentally get started while the non-default context is active.
Beware that libraries that predate this function may not correctly handle being used from a thread with a thread-default context. Eg, see g_file_supports_thread_contexts().