GNOME Bugzilla – Bug 793831
g_app_info_launch_default_for_uri_async is not really async
Last modified: 2018-05-24 20:15:54 UTC
The first call is launch_default_for_uri which is all sync. Specifically, g_file_query_default_handler blocks in case the file is in a ssh server that is down. Most probably the best approach would be to make the whole g_app_info_launch_default_for_uri_async a GTask wrapper of g_app_info_launch_default_for_uri. See https://gitlab.gnome.org/GNOME/nautilus/issues/266 for the original report against Nautilus. Here's the backtrace or where is blocking:
+ Trace 238433
Just a note, that this slightly corresponds to the following bug and can end up with a common fix... https://bugzilla.gnome.org/show_bug.cgi?id=780296
Created attachment 368999 [details] [review] gappinfo: Make async API really async g_app_info_launch_default_for_uri_async calls various GFile and GDesktopAppInfo synchronous methods. This causes troubles especially in case of unaccessible filesystem. Given the fact that the whole GDesktopAppInfo API is synchronous, let's simply use GTask thread to call g_app_info_launch_default_for_uri.
Review of attachment 368999 [details] [review]: LGTM fwiw
Review of attachment 368999 [details] [review]: ::: gio/gappinfo.c @@ +778,3 @@ + context = g_object_get_data (G_OBJECT (task), "context"); + + if (g_app_info_launch_default_for_uri (uri, context, &error)) The GAppLaunchContext isn’t thread-safe, so you can’t technically do this. I suspect the only way to fix this is to add launch_uris_async and launch_uris_finish vfuncs to GAppInfoIface and plumb them all the way through to here. Then the implementation of GAppInfo can decide whether to use a thread (or whether to poll); and if it uses a thread, it can use appropriate locking. @@ +815,3 @@ + g_object_set_data_full (G_OBJECT (task), "uri", g_strdup (uri), g_free); + if (context != NULL) + g_object_set_data_full (G_OBJECT (task), "context", g_object_ref (context), g_object_unref); Use g_task_set_task_data() to avoid creating a pointless qdata hash table in the GTask: typedef struct { gchar *uri; GAppLaunchContext *context; } LaunchDefaultForUriData; static void launch_default_for_uri_data_free (LaunchDefaultForUriData *data) { g_free (data->uri); g_object_unref (data->context); g_free (data); } { LaunchDefaultForUriData *data = NULL; … data = g_new0 (LaunchDefaultForUriData, 1); data->uri = g_strdup (uri); data->context = g_object_ref (context); g_task_set_task_data (task, g_steal_pointer (&data), (GDestroyNotify) launch_default_for_uri_data_free); … }
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1347.