GDBusConnection: when to close, when to unref

Simon McVittie simon.mcvittie at
Fri Jun 7 03:30:36 PDT 2013

On 07/06/13 06:50, Lars Hanisch wrote:>  First I use g_bus_get to
connect to the system- resp. session-bus.
>  In the first case I assume, that I don't have to use
> g_dbus_connection_close since that are shared connections, right?
>  But do I have to g_object_unref the connection object?

Do not g_dbus_connection_close() - you would break other modules.

Do g_object_unref() when you've finished with it. If you release the
last reference, it may close, in which case the next g_bus_get() would
open a new one. (This is not the same as libdbus, in which the library
holds an extra reference to each shared connection.)

Note that keeping a reference, i.e. keeping the same connection open for
the duration of your application, is probably more efficient - if you
have a "big object" with a long lifetime, like Telepathy's
TpAccountManager, it's probably a good idea for it to hold a reference
to the appropriate bus.

>  OTOH I use g_dbus_connection_new_for_address to connect to a third
> dbus-daemon, which is listening on a tcp port.
>  In the second case, where I create a new connection, do I have to
> close it? And what about g_object_unref?

Private connections are like file objects: it's best to
close-then-unref. It is not an error to just do the unref, but that way
you can't detect errors, and if you have leaked a ref somewhere, the
connection will remain open.

(This is not the same as libdbus, in which you must close private
connections before releasing their last ref, and you have to clear the
exit-on-close flag first, otherwise libdbus will exit your process.
GDBus doesn't exit when a connection is locally-closed, only when
remotely-closed, and the exit-on-close flag for GDBus private
connections is off by default anyway.)


More information about the dbus mailing list