+
+ <para>Queued but unwritten/unread messages also keep a reference
+ to their bus connection object. For this reason, even if an
+ application dropped all references to a bus connection, it might
+ not get destroyed right away. Until all incoming queued
+ messages are read, and until all outgoing unwritten messages are
+ written, the bus object will stay
+ alive. <function>sd_bus_flush()</function> may be used to write
+ all outgoing queued messages so they drop their references. To
+ flush the unread incoming messages, use
+ <function>sd_bus_close()</function>, which will also close the bus
+ connection. When using the default bus logic, it is a good idea to
+ first invoke <function>sd_bus_flush()</function> followed by
+ <function>sd_bus_close()</function> when a thread or process
+ terminates, and thus its bus connection object should be
+ freed.</para>
+
+ <para>The life cycle of the default bus connection should be the
+ responsibility of the code that creates/owns the thread the
+ default bus connection object is associated with. Library code
+ should neither call <function>sd_bus_flush()</function> nor
+ <function>sd_bus_close()</function> on default bus objects unless
+ it does so in its own private, self-allocated thread. Library code
+ should not use the default bus object in other threads unless it
+ is clear that the program using it will life cycle the bus
+ connection object and flush and close it before exiting from the
+ thread. In libraries where it is not clear that the calling
+ program will life cycle the bus connection object, it is hence
+ recommended to use <function>sd_bus_open_system()</function>
+ instead of <function>sd_bus_default_system()</function> and
+ related calls.</para>
+ </refsect1>
+
+ <refsect1>
+ <title>Return Value</title>
+
+ <para>On success, these calls return 0 or a positive
+ integer. On failure, these calls return a negative
+ errno-style error code.</para>