]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
man/sd_bus_process: fix confusion about "synchronous"
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Thu, 16 Nov 2023 10:12:00 +0000 (11:12 +0100)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Thu, 23 Nov 2023 12:23:44 +0000 (13:23 +0100)
An event loop is not "synchronous". So we shouldn't say that the client must
"synchrounusly poll" if we recommend an event loop. Let's just say it should
poll, and say that "sd_bus_wait()" is blocking, which is clearer and more
correct than "synchronous".

man/sd_bus_process.xml

index f16b30ec6c94098ac012eccaaa2f5b37f680519d..8e142dd97a7a488f38558a8ba24419b968f9baaa 100644 (file)
   <refsect1>
     <title>Description</title>
 
-    <para><function>sd_bus_process()</function> drives the connection between the client and the message bus. That is,
-    it handles connecting, authentication, and message processing. When invoked pending I/O work is executed, and
-    queued incoming messages are dispatched to registered callbacks. Each time it is invoked a single operation is
-    executed. It returns zero when no operations were pending and positive if a message was processed. When zero is
-    returned the caller should synchronously poll for I/O events before calling into
-    <function>sd_bus_process()</function> again. For that either use the simple, synchronous
-    <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> call, or hook up
-    the bus connection object to an external or manual event loop using
+    <para><function>sd_bus_process()</function> drives the connection between the client and the message bus.
+    That is, it handles connecting, authentication, and processing of messages. When invoked, pending I/O
+    work is executed, and queued incoming messages are dispatched to registered callbacks. Each time it is
+    invoked a single operation is executed. It returns zero when no operations were pending and positive if a
+    message was processed. When zero is returned the caller should poll for I/O events before calling into
+    <function>sd_bus_process()</function> again. For that either use the simple, blocking
+    <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> call, or
+    hook up the bus connection object to an external or manual event loop using
     <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
     </para>