luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-25 03:32:12 +01:00
Code Issues Packages Projects Releases Wiki Activity

Fix initialization logic of GThreadPool if the first created pool is an exclusive one

Browse Source 
Previously we would only ever run the initialization code once, but part
of it only if a non-exclusive pool was created. This caused the shared
state to be inconsistent if the first pool to be created was exclusive
and the second non-exclusive.

Fixes https://gitlab.gnome.org/GNOME/glib/issues/2012
This commit is contained in:
Sebastian Dröge 2020-01-25 11:08:22 +02:00
parent ac0c0b5b28
commit 78bae85d21
1 changed files with 33 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
glib/gthreadpool.c
View File

@ -579,8 +579,8 @@ g_thread_pool_new (GFunc func,
G_LOCK (init);
if (!unused_thread_queue)
{
unused_thread_queue = g_async_queue_new ();
/* For the very first non-exclusive thread-pool we remember the thread
* scheduler settings of the thread creating the pool, if supported by
* the GThread implementation. This is then used for making sure that
@ -603,7 +603,7 @@ g_thread_pool_new (GFunc func,
* are created immediately below and are running forever, so they will
* automatically inherit the scheduler settings from this very thread.
*/
if (!exclusive)
if (!exclusive && !have_shared_thread_scheduler_settings && !spawn_thread_queue)
{
if (g_thread_get_scheduler_settings (&shared_thread_scheduler_settings))
{
@ -616,7 +616,6 @@ g_thread_pool_new (GFunc func,
g_thread_new ("pool-spawner", g_thread_pool_spawn_thread, NULL);
}
}
}
G_UNLOCK (init);
if (retval->pool.exclusive)