GDBusConnection: when to close, when to unref
Lars Hanisch
dvb at flensrocker.de
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. :)
Lars.
More information about the dbus
mailing list