GDBusConnection: when to close, when to unref

Lars Hanisch dvb at
Fri Jun 7 09:11:45 PDT 2013

Am 07.06.2013 12:30, schrieb Simon McVittie:
> 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.)

 Ok, I won't - and I understand why. :)

> 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.

 The connections are held open as long as possible. They're closed and reopened if there is a connection related error
(like the remote dbus-daemon exits or similiar). My application should survive even system-dbus-restarts. Of course I
clear the exit-on-close-flag on every connection so I have full control on the life time of my program.

>>  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.)

 Thanks for clarifing! Step by step I get used to GDBus and asynchronous programming. Should have learned that years
ago. Happily I do now. :)


More information about the dbus mailing list