Drop the Big GDK Lock

GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.

Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.

During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.

https://bugzilla.gnome.org/show_bug.cgi?id=793124

1 files changed, 0 insertions, 6 deletions

diff --git a/gtk/gtkrecentmanager.c b/gtk/gtkrecentmanager.c
index d6806da57c..ed370183b3 100644
--- a/gtk/gtkrecentmanager.c
+++ b/gtk/gtkrecentmanager.c
@@ -546,9 +546,7 @@ gtk_recent_manager_monitor_changed (GFileMonitor      *monitor,
     case G_FILE_MONITOR_EVENT_CHANGED:
     case G_FILE_MONITOR_EVENT_CREATED:
     case G_FILE_MONITOR_EVENT_DELETED:
-      gdk_threads_enter ();
       gtk_recent_manager_changed (manager);
-      gdk_threads_leave ();
       break;
 
     case G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT:
@@ -814,8 +812,6 @@ gtk_recent_manager_add_item_query_info (GObject      *source_object,
   recent_data.groups = NULL;
   recent_data.is_private = FALSE;
 
-  gdk_threads_enter ();
-
   /* Ignore return value, this can't fail anyway since all required
    * fields are set
    */
@@ -824,8 +820,6 @@ gtk_recent_manager_add_item_query_info (GObject      *source_object,
   manager->priv->is_dirty = TRUE;
   gtk_recent_manager_changed (manager);
 
-  gdk_threads_leave ();
-
   g_free (recent_data.mime_type);
   g_free (recent_data.app_name);
   g_free (recent_data.app_exec);