After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708828 - GDBusProxy: add the ability to call methods on non autostarted proxies
GDBusProxy: add the ability to call methods on non autostarted proxies
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gdbus
unspecified
Other All
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-09-26 11:22 UTC by Giovanni Campagna
Modified: 2013-10-04 00:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDBusProxy: add the ability to call methods on non autostarted proxies (3.08 KB, patch)
2013-09-26 11:22 UTC, Giovanni Campagna
rejected Details | Review
GDBusProxy: add flag to control autostarting at construction time (4.16 KB, patch)
2013-10-03 18:27 UTC, Giovanni Campagna
committed Details | Review

Description Giovanni Campagna 2013-09-26 11:22:02 UTC
Previously a program using GDBusProxy had two choices: it could
either use NO_AUTO_START, and then wait until the service appeared
to make the call, or don't pass the flag and have the service autostarted
when creating the proxy.
In some cases though it is more practical to create the proxy
eagerly, even if its not needed until later, so the service
should not be started automatically and DBus activation should only
happen later when a method is called.
To do so, add a new flag, CALL_WELL_KNOWN_NAME, that overrides
NO_AUTO_START and allows to make method calls on an inactive proxy.
Comment 1 Giovanni Campagna 2013-09-26 11:22:04 UTC
Created attachment 255819 [details] [review]
GDBusProxy: add the ability to call methods on non autostarted proxies
Comment 2 David Zeuthen (not reading bugmail) 2013-09-26 19:38:50 UTC
I don't think this is a good idea as it introduces a race-condition insofar that you don't really know which process will receive the method call. Which goes against a key design goal of GDBusProxy - that you're dealing with an object from a single process, not properties from one process and method invocations on another one.
Comment 3 David Zeuthen (not reading bugmail) 2013-09-26 19:40:20 UTC
Perhaps you could explain why you think this is needed. It could be that the problem exists on a higher level and there's a way to work around it.
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-09-26 19:42:58 UTC
(In reply to comment #3)
> Perhaps you could explain why you think this is needed. It could be that the
> problem exists on a higher level and there's a way to work around it.

gnome-shell search results use auto-started DBus services that automatically exit after a timeout. We want to prevent the DBus service from starting when we initially create the proxy, and defer it to when we call the first method to prevent unnecessary DBus traffic during gnome-shell startup.

Perhaps we should create the DBus proxy in gnome-shell code when we actually need them, and destroy them when the process times out. But the existence of how these services time out sort of already breaks your "one process" invariant.
Comment 5 Giovanni Campagna 2013-09-27 07:41:14 UTC
I would strongly oppose the idea of creating the proxies on demand. It really defeats the point of a proxy as an object that represents the remote service, and would complicate the gnome-shell code unnecessarily.

Note also that in this specific case we don't care about properties, only methods. Also, the race condition already exists: the process can exit but you might not get the NameOwnerChanged before the next method call.
Comment 6 Colin Walters 2013-09-27 14:54:47 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Perhaps you could explain why you think this is needed. It could be that the
> > problem exists on a higher level and there's a way to work around it.
> 
> gnome-shell search results use auto-started DBus services that automatically
> exit after a timeout. We want to prevent the DBus service from starting when we
> initially create the proxy, and defer it to when we call the first method to
> prevent unnecessary DBus traffic during gnome-shell startup.


From discussion on #gtk+ related to software, I was arguing that for this sort of case, you use g_bus_watch_name() with G_BUS_NAME_WATCHER_FLAGS_AUTO_START.  In the vanished callback, check if you have started it once.  If so, then remove the watch, and add it back, causing the process to autostart again.
Comment 7 Giovanni Campagna 2013-10-02 13:55:01 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Perhaps you could explain why you think this is needed. It could be that the
> > > problem exists on a higher level and there's a way to work around it.
> > 
> > gnome-shell search results use auto-started DBus services that automatically
> > exit after a timeout. We want to prevent the DBus service from starting when we
> > initially create the proxy, and defer it to when we call the first method to
> > prevent unnecessary DBus traffic during gnome-shell startup.
> 
> 
> From discussion on #gtk+ related to software, I was arguing that for this sort
> of case, you use g_bus_watch_name() with G_BUS_NAME_WATCHER_FLAGS_AUTO_START. 
> In the vanished callback, check if you have started it once.  If so, then
> remove the watch, and add it back, causing the process to autostart again.

That's the opposite way around. We don't want to autostart the service until we make the first call, and we don't want to keep it alive.
Comment 8 David Zeuthen (not reading bugmail) 2013-10-02 19:43:04 UTC
I think if we had a flag like this
 
 @G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION:
 Like  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START but only at construction time.
 This is useful if you deal with transient well-known services that you do
 not want to launch at proxy-construction time.

you could use that?
Comment 9 Giovanni Campagna 2013-10-02 20:49:36 UTC
(In reply to comment #8)
> I think if we had a flag like this
> 
>  @G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION:
>  Like  G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START but only at construction time.
>  This is useful if you deal with transient well-known services that you do
>  not want to launch at proxy-construction time.
> 
> you could use that?

Yes, that would be the necessary semantics, and it is what my patch implements, although I used two flags, with one having negative effects.
The negative flag might be confusing, I agree, but NO_AUTO_START_AT_CONSTRUCTION seems overly long...
Comment 10 David Zeuthen (not reading bugmail) 2013-10-03 18:09:01 UTC
I don't think G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION is that scary. And it's certainly less contradictory than G_DBUS_PROXY_FLAGS_CALL_WELL_KNOWN_NAME given that we already use the well-known name if there currently is no owner [1].

[1] : this is even documented as: "However, if no name owner currently exists, then calls will be sent to the well-known name which may result in the message bus launching an owner (unless G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START is set)."
Comment 11 Giovanni Campagna 2013-10-03 18:27:32 UTC
Created attachment 256414 [details] [review]
GDBusProxy: add flag to control autostarting at construction time

Sometimes the application doesn't want to autostart a service
when it creates a proxy, but wants the service autostarted when
it makes the first method call. Allow that behavior with a new
flag.
Comment 12 David Zeuthen (not reading bugmail) 2013-10-03 20:01:04 UTC
Comment on attachment 256414 [details] [review]
GDBusProxy: add flag to control autostarting at construction time

Cool - thanks for renaming it! Cheers.
Comment 13 Giovanni Campagna 2013-10-04 00:38:54 UTC
Attachment 256414 [details] pushed as 32d2539 - GDBusProxy: add flag to control autostarting at construction time