From b938cb902c3b5bca807a94b277672c64d6767886 Mon Sep 17 00:00:00 2001 From: Jan Engelhardt Date: Sun, 3 Aug 2014 07:11:12 +0200 Subject: doc: correct punctuation and improve typography in documentation --- man/sd_bus_default.xml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) (limited to 'man/sd_bus_default.xml') diff --git a/man/sd_bus_default.xml b/man/sd_bus_default.xml index 1cf2cb8f9a..2160b76762 100644 --- a/man/sd_bus_default.xml +++ b/man/sd_bus_default.xml @@ -112,7 +112,7 @@ connection object to the user bus when invoked in user context, or to the system bus otherwise. The connection object is associated with the calling thread. Each time the function is invoked from - the same thread the same object is returned, but its reference + the same thread, the same object is returned, but its reference count is increased by one, as long as at least one reference is kept. When the last reference to the connection is dropped (using the @@ -120,7 +120,7 @@ call), the connection is terminated. Note that the connection is not automatically terminated when the associated thread ends. It is important to drop the last reference to the bus connection - explicitly before the thread ends or otherwise the connection will + explicitly before the thread ends, or otherwise, the connection will be leaked. Also, queued but unread or unwritten messages keep the bus referenced, see below. @@ -140,7 +140,7 @@ connects to the system bus. In contrast to sd_bus_default(), sd_bus_default_user(), - sd_bus_default_system() these calls return + sd_bus_default_system(), these calls return new, independent connection objects that are not associated with the invoking thread and are not shared between multiple invocations. It is recommended to share connections per thread to @@ -215,31 +215,31 @@ 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 + 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. sd_bus_flush() may be used to write all outgoing queued messages so they drop their references. To - flush the unread incoming messages use + flush the unread incoming messages, use sd_bus_close(), which will also close the bus - connection. When using the default bus logic it is a good idea to + connection. When using the default bus logic, it is a good idea to first invoke sd_bus_flush() followed by sd_bus_close() when a thread or process terminates, and thus its bus connection object should be freed. - The life-cycle of the default bus connection should be the + 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 sd_bus_flush() nor sd_bus_close() 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 + 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 + program will life cycle the bus connection object, it is hence recommended to use sd_bus_open_system() instead of sd_bus_default_system() and related calls. -- cgit v1.2.3-54-g00ecf