D-BUS in KDE

[Havoc Pennington]

On Fri, 2004-10-01 at 11:57 +0200, Harald Fernengel wrote:
> Hi,
> 
> there is currently a heated discussion going on in kde-core-devel about the 
> adaption of D-BUS 
> (http://lists.kde.org/?l=kde-core-devel&m=109646893512881&w=2).
> 

Oh fun ;-) I'll have to go read that.

> One of the points for D-COP over D-BUS is that D-COP tries to handle 
> reentrancy/deadlock situations by tracing calling paths 
> (http://lists.kde.org/?l=kde-core-devel&m=109656397625022&w=2). Since I'm not 
> too familiar with the D-BUS internals, can someone clear that point up?

If I understand right, I discussed this with Matthias Ettrich a bit,
there is an item in doc/TODO about it:

 - when making a method call, if the call serial were globally unique,
   we could forward the call serial along with any method calls made
   as a result of the first method call, and allow reentrancy that was
   strictly part of the call stack of said method call. But I don't
   really see how to do this without making the user pass around the
   call serial to all method calls all the time, or disallowing 
   async calls.

   If done post 1.0 will probably be an optional/ugly-API type 
   of thing.

By "optional/ugly" what I mean is something like, right now we have
new_reply() for sending a method call reply, we could add a 
new_reply_with_call_serial() that took the unique number.

The optional/ugly aspect would not impact bindings such as the Qt
bindings since they could probably handle it automatically.
The whole low-level libdbus is ugly anyhow so it's sort of irrelevant.

My view on deadlocks was basically, a) write the code async or b) use
threads ... 

Another option that might help is the "multiple message queues" 
or "socket multiplexing" idea previously posted. We could effectively
have a message queue per-object or per-code-module and allow the queue
to be set blocking, nonblocking, etc.

This is worth thinking about hard and getting Really Right in my
opinion, though I don't think it can be made totally trivial/transparent
to the app developer, unfortunately.

Havoc