GNOME Bugzilla – Bug 744625
Search provider should not spawn miners and set the tracker priority
Last modified: 2015-03-06 15:40:38 UTC
Doing a search in gnome-shell with the gnome-documents search provider enabled results in an unreasonably large number of processes being created, including the gnome-online-miners for gdata, zpj and owncloud. This is particularly surprising because I don't have accounts configured for any of these things. I verified that gnome-documents was to blame by disabling all search providers and doing a search (no miners created) and then doing a search with only gnome-documents enabled (lots of miners created). gnome-photos has a similar bug, which I will file separately.
Created attachment 296984 [details] [review] application: Spawn the miners only when a window is created
Created attachment 296987 [details] [review] application: Set priority rdf:types only when a window is created
Review of attachment 296984 [details] [review]: Shouldn't this be done by setting G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START instead?
Review of attachment 296987 [details] [review]: Looks good
(In reply to Cosimo Cecchi from comment #3) > Review of attachment 296984 [details] [review] [review]: > > Shouldn't this be done by setting G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START > instead? I thought about that, but: 1) The difference between G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION and G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START was not obvious after reading the documentation, and quickly looking at the code. It appears as if we need G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION. 2) Gio.DBusProxy.makeProxyWrapper does not let me pass any flags. 3) Reducing the number of things that we do when launching the search provider is probably a good idea any way. Maybe we should use the flag *and* move the proxies out of startup? I will play with the flags and gnome-photos and see how it works out.
(In reply to Debarshi Ray from comment #5) > (In reply to Cosimo Cecchi from comment #3) > > Review of attachment 296984 [details] [review] [review] [review]: > > > > Shouldn't this be done by setting G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START > > instead? > > 3) Reducing the number of things that we do when launching the search > provider is probably a good idea any way. Maybe we should use the flag *and* > move the proxies out of startup? Particularly because we are creating these synchronously, which is convenient but useless for the search provider.
So, yes, G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION is what we want. See the patch for gnome-photos in bug 744627 where I did it that way.
I'm fine with doing both the things you propose, even though we could easily make the construction asynchronous without complicating it too much (gjs will return the GAsyncInitable when async construction is requested IIRC). I guess we'll have to call new Gio.DBusProxy() manually to set the flag instead of using the GJS convenience... :-(
(In reply to Cosimo Cecchi from comment #8) > I'm fine with doing both the things you propose, even though we could easily > make the construction asynchronous without complicating it too much (gjs > will return the GAsyncInitable when async construction is requested IIRC). The function returned by makeProxyWrapper accepts an asynCallback parameter. The proxy construction becomes asynchronous if that is passed. Let's make them asynchronous and move them out of startup into window creation. > I guess we'll have to call new Gio.DBusProxy() manually to set the flag > instead of using the GJS convenience... :-( If we have moved them into window creation, then we will end up calling RefreshDB (hence spawning the processes) immediately. Therefore, setting the DO_NOT_AUTO_START_AT_CONSTRUCTION flag does not buy us anything.
Created attachment 297081 [details] [review] application: Create the miner proxies asynchronously
Created attachment 297245 [details] [review] application: Create the miner proxies asynchronously Avert another possible race.
We are entering the freezes. I am pushing them so that we don't miss them for the final release.