GNOME Bugzilla – Bug 708744
GDaemonFileEnumerator registers itself on *all* dbus connections
Last modified: 2013-10-03 11:41:26 UTC
g_daemon_file_enumerator_new() calls: _g_dbus_register_vfs_filter (path, register_vfs_filter_cb, G_OBJECT (daemon)); and later (e.g in create_proxy_for_file2) we call _g_dbus_connect_vfs_filters() for *all* dbus connections used by any dbus thread (e.g. for each per-thread-and-per-mountpoint peer-to-peer connection). This means register_vfs_filter_cb will be called in random thread using gvfs for each dbus connection ever used, where it will create a new skeleton. I don't think this makes any sense. The callbacks from a single enumerate_children() will all be on a particular connection (i.e. the one we sent the request to), there is no need for all the others.
*** Bug 708721 has been marked as a duplicate of this bug. ***
Turns out that this is not only wasteful, but can lead to threadsafety issues as per bug 708721.
Created attachment 255809 [details] [review] GDaemonFileEnumerator: Only listen to messages one connection There is no need to listen to messages on other connections than the one we sent the request on. In fact, doing so is bad as it can cause locking issues as per bug 708721.
Created attachment 255810 [details] [review] GDaemonFileMonitor: Only recieve events on one dbus connection There is no need to register for monitor evens on all dbus connections, just the one we send the request on.
Created attachment 255811 [details] [review] client: Remove unused code for dbus vfs filters This code is not used anymore
Attachment 255809 [details] pushed as 65b8b93 - GDaemonFileEnumerator: Only listen to messages one connection Attachment 255810 [details] pushed as a302823 - GDaemonFileMonitor: Only recieve events on one dbus connection Attachment 255811 [details] pushed as 8d08c55 - client: Remove unused code for dbus vfs filters
I haven't done much testing yet, but this looks very good. Thank you! You probably also want to remove the global obj_path_map in gvfsdaemonbus.c as it is not any longer used after your changes.
Removed by the Bug 591228.
This patch appears to cause some trouble when using Thunar or PCManFM in the current Ubuntu development release (gvfs 1.18.1). https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1231978
Ok, repopening then. Do we have a backtrace of the hangs?
Created attachment 256356 [details] [review] client: Don't user g_source_remove() on non-default main context We created a GSource, attached it to a non-default main context and then removed it via g_source_remove, which removed the source with the same id on the main context, which typically was the X fd, causing everything to stop working! Non-default main contexts must use g_source_destroy()
Attachment 256356 [details] pushed as 33df421 - client: Don't user g_source_remove() on non-default main context