care should be taken to use a division that rounds up to ensure the I/O polling operation
doesn't sleep for shorter than necessary, which might result in unintended busy looping
(alternatively, use
- <citerefentry project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+ <citerefentry project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum></citerefentry>
instead of plain <function>poll()</function>, which understands timeouts with nano-second
granularity).</para>
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 user the simple, synchronous
+ <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
<citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
function is supposed to be called whenever
<citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns zero,
indicating that no work is pending on the connection. Internally, this call invokes <citerefentry
- project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>3</manvolnum></citerefentry>, to wait for I/O on
+ project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, to wait for I/O on
the bus connection. If the <parameter>timeout_sec</parameter> parameter is specified, the call will block at most
for the specified amount of time in µs. Pass <constant>UINT64_MAX</constant> to permit it to sleep
indefinitely.</para>