Re: sd-bus: calling D-Bus method from a D-Bus method callback upon the same D-Bus connection

[Simon McVittie <smcv@xxxxxxxxxxxxx>]

On Sat, 26 Jan 2019 at 16:22:47 +0100, Lennart Poettering wrote:
> Yes, you may synchronously call into other bus services from an async
> msg hander, but as long as that call runs no incoming msgs besides the
> expected reply will be processed. This means effectively that while
> the synchronous call is running all incoming messages are queued until
> the reply is seen, then the reply is processed and the call returns,
> and only then after you return back into the event loop the queued
> incoming messages are dispatched.
> 
> This also means that while in dbus normally everything is strictly
> ordered, if you do things in this way the reply is "pulled ahead"
> during processing, and the other msgs incoming "pushed back".

For what it's worth, it sounds as though this is the same behaviour as in other
popular D-Bus implementations. In libdbus (the reference implementation) there
is a convention that the functions that behave like this mostly end with
_block, for example dbus_connection_send_message_with_reply_and_block(). In
GDBus (part of GLib) they conventionally end with _sync, for example
g_dbus_connection_call_sync(). In Qt they use mode QDBus::Block. Any advice or
warnings you see about those API families will probably apply equally to the
equivalents in sd-bus.

Reiterating what Lennart said, if you don't use synchronous/blocking calls,
D-Bus messages via the dbus-daemon or a reimplementation like dbus-broker are
usually seen in the same order by everyone on the bus (a mathematician would
say there's a "total order" on the set of messages). If you use
synchronous/blocking calls, you lose that guarantee, because you are processing
some messages out-of-order.

See also http://smcv.pseudorandom.co.uk/2008/11/nonblocking/ (which was written
before the addition of sd-bus and GDBus and the deprecation of dbus-glib, but
is otherwise still relevant).

    smcv
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel