FAQ notes

[Havoc Pennington]

Jeroen T. Vermeulen wrote:
> On Mon, August 21, 2006 09:19, Havoc Pennington wrote:
> 
>> Yep. For example a legitimate implementation is that every method call
>> runs asynchronously in a separate thread.
> 
> And another message-ordering question...  Why you're waiting for a reply
> from a synchronous method invocation, I presume there's no problem with
> other messages (signals, say, or replies from earlier asynchronous method
> invocations) arriving in the meantime?
> 
> Probably a silly question--it's just that I'm trying to document this
> stuff...
> 

Not at all, this is one of the key questions when designing an IPC thingy.

It depends a little bit how you are making the call. If you're letting 
dbus block for you (e.g. send_with_reply_and_block()) then what will 
happen is that other messages arriving will be queued, but not 
dispatched. So from the application's perspective, there won't be any 
callbacks invoked while blocking. (Unless threads come into it, in which 
case one thread could block while another kept processing the queue.)

If you've set up a callback (dbus_pending_call_set_notify) for when you 
get the reply, instead of blocking, then of course other messages will 
keep getting dispatched in the meantime.

Even replies from *later* async method invocations can arrive while 
waiting for a reply... method replies don't have to come in the same 
order as the calls, though if you're talking to a remote app that only 
has one thread, they will be naturally kept in order since that app will 
fully process and reply to each call in serial.

The tradeoff here is that by not dispatching calls while blocking, 
deadlocks are possible; this is the default for whenever dbus blocks, 
though, because deadlocks are pretty easy to debug (and fix by switching 
to some async calling convention for that method), relative to 
"uncontrolled reentrancy" ("any time you make a call any other call can 
be made as a side effect").

There's some stuff in the thread archives that goes into more detail 
discussing said tradeoff.

Havoc