Revision 72ed9e04394746495f021133915e6bf7c1d3b5b1 authored by Michael Catanzaro on 25 May 2019, 23:30:12 UTC, committed by Michael Catanzaro on 26 May 2019, 15:17:15 UTC
The GTask must be destroyed on the thread that is running its GMainContext, i.e. the thread that started the task. It must never be destroyed on the actual task thread when running with g_task_run_in_thread(), because when it is destroyed, it will unref its source object and destroy its user data (if a GDestroyNotify was set for the data using g_task_set_task_data()). The source object and task data might not be safe to destroy on a secondary thread, though, so this is incorrect. We have to ensure they are destroyed on the task's context's thread. There are different ways we could do this, but the simplest by far is to ensure the task thread has unreffed the task before the context's thread executes the callback. And that is simple enough to do using a condition variable. We have to keep a static global map of all GTasks with outstanding task threads, which is slightly unfortunate, but we already have a bunch of global data in this file for managing the thread pool, and the map will only contain tasks that are currently running in threads, so it should be small. Fixes #1346
1 parent e10eff1
README.rationale
This file documents various major decisions which affect GLib development,
giving a brief rationale of each decision, plus a link to further discussion.
* Compiler attributes: https://bugzilla.gnome.org/show_bug.cgi?id=113075#c46
GLib uses GIR annotations instead of compiler attributes. They are tidier,
already supported by GLib and GNOME tools, and accomplish the same task as
compiler attributes. GLib does not provide macros for attributes like
nonnull because it would not use them.
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...