FAQ notes

[Thiago Macieira]

Jeroen T. Vermeulen wrote:
>Here's a question that might be nice for the FAQ: what, if any,
> guarantees on message ordering does d-bus make?  It's one of the first
> things I wondered about, but I haven't come across any documentation on
> it.

This is a multi-layered question...

The D-Bus daemon follows a strict FIFO order: any message received is 
immediately dispatched to its destinations before further messages are 
received.

The D-Bus library is also FIFO under normal conditions: messages are 
processed in the order they are received. So, for a program that is 
waiting in its idle loop and receives a series of messages, they'll be 
each delivered to the binding in order.

However, the library also allows for some de-ordering: you can spy on the 
message queue and steal messages from it. Also, when you're on a blocking 
wait for a method reply, that reply will be delivered to you, skipping 
other messages that may have been received.

Bindings can further complicate stuff, if they decide to reorder. For some 
time, the Qt binding did that and some types of messages had higher 
priority than others.

>As the simplest case, let's say I want to call methods foo and bar on an
>object--in that order.  Let's also say I don't care about the results
>until afterwards.  Any information that flows from one call to the next
> is held by the object; if foo fails, bar will not do anything harmful. 
> The only thing I really care about is that I'd like to foo and bar to
> succeed, and if they do, they must do so in the right order.
>
>In a situation like this, I might be tempted to fire off two
> asynchronous calls to foo and bar, and then await responses for both. 
> Does d-bus guarantee that the calls will arrive at the object in the
> same order in which I sent them off?

Yes, the D-Bus daemon and library will deliver those calls to the other 
program in order. Whether the other program's bindings or code de-order 
them, that's another question.

Generally speaking, method calls should be safe, since there's no 
particular reason for one spontaneous call to be handled before another 
one. Same for signals.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060829/b8c80c2f/attachment.pgp