DBus GObject & g_object_unref
Havoc Pennington
hp at redhat.com
Mon Jul 31 15:33:12 PDT 2006
Marc-André Lureau wrote:
> Given a gobject service:
> dbus_g_connection_register_g_object (bus, "/SomeObject", G_OBJECT (obj));
>
> This gobject could release the service he provides, this way:
> g_object_unref (obj);
> and dbus_g_proxy_call (bus_proxy, "ReleaseName", &error,
> G_TYPE_STRING, "org.designfu.SampleService",
> G_TYPE_INVALID,
> G_TYPE_UINT, &request_name_result,
> G_TYPE_INVALID))
>
> I would like to have a proxy notified when the gobject service has
> released the service, or
> has been destroyed.
> proxy = dbus_g_proxy_new_for_name_owner (bus,
> "org.designfu.SampleService ",
> "/SomeObject", "org.designfu.SampleInterface",
> &error);
> either with a weak ref:
> g_object_weak_ref (proxy, (GWeakNotify)_proxy_destroy, NULL);
> or a distroy signal (I use the "name_owner" proxy):
> g_signal_connect(proxy, "destroy",
> G_CALLBACK(_proxy_destroy), proxy);
>
> Unfortunately, the proxy destroy signal is emited only when the process
> where the service-object is living is terminated (killed or exited).
>
> I think it's related to a "1:xxx" id still on the bus after the unref...
>
> I hope you will understand what I am talking about, I am sorry to have a so
> poor english and not a deep understanding of dbus...
Thanks, I think I understand now. Because you're using
new_for_name_owner(), the proxy is attached to the *process* represented
by the unique name (":1.xxxx").
The proxy only uses org.designfu.SampleService to initially locate the
process, but then it's associated with the "name owner" not with the name.
Usually this is what you want, because otherwise the remote process can
change in the middle of a conversation.
I think what you have to do here is simply listen for the
NameOwnerChanged signal and create a new proxy when the owner changes.
If you avoid the word "service" I think you'll find things are clearer;
instead, specifically think about either processes (connections to the
bus) or names that those processes have.
Havoc
More information about the dbus
mailing list