Reliability of the D-Bus broadcast messages

David Zeuthen zeuthen at gmail.com
Tue Mar 22 06:00:01 PDT 2011


Hi,

On Tue, Mar 22, 2011 at 5:17 AM, Dean Jenkins <djenkins at mvista.com> wrote:
> Hi Havoc,
>
> On 21 March 2011 20:28, Havoc Pennington <hp at pobox.com> wrote:
>> Signals do not have replies and cannot be reliable in this sense, though.
>>
> Please can you clarify what you meant by "reliability" wrt to signals.
> For example, if a D-bus client application registers an interest in a
> signal and the D-bus server application sends that signal, is the
> client application guaranteed to receive that signal ?
>
> I am asking because we see D-bus monitor showing signals being sent
> but out client application only receives 3 out 5 signals. Obviously
> that breaks our application. It could be bug in our application but I
> just wanted to check that it is not a flaw in D-bus that prevents
> signals not being received 100% of the time.

You are indeed guaranteed that signals are never lost - it would be
difficult to write any meaningful application synchronizing state
between a server and a client process without this guarantee...

That said, for the app emitting the signal, make sure all buffers are
flushed before exiting (this is a very common mistake). With GDBus,
this is achieved by e.g. g_dbus_connection_flush()

   http://library.gnome.org/devel/gio/unstable/GDBusConnection.html#g-dbus-connection-flush

or if using libdbus I believe it's

   http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga10e68d9d2f41d655a4151ddeb807ff54

FWIW, I know the dbus-daemon(1) bits of this work just fine because I
have a test-case in GDBus for this for testing
g_dbus_connection_flush() + friends:

 http://git.gnome.org/browse/glib/tree/gio/tests/gdbus-connection-slow.c?id=2.28.4#n58

Hope this helps.

    David


More information about the dbus mailing list