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