Fwd: Circular calls with DBUS

[Matthew Johnson]

For those on the list, this thread is about reentrant calls in D-Bus;
that is when application A makes a call on application B, and
application B's handler for that call makes another call back to
application A. Jacques thought this could be handled more nicely if a
'call trace' was stored in the header of each message so that the second
call was associated with the first.

On Thu, Mar 22, 2007 at 06:19:52PM +0100, Jacques Guillou wrote:
> What do you mean by "hiding the problems just makes thm more obscure and
> harder to track down" ?
> If this information was somewhere in the protocol, it would have been easy
> to implement a dispatching mechanism which works in such a way that any
> component can be used either locally or remotely, without any necessary
> change concerning "thread safety".
> 
> But without this information, I think we just can't implement such a thing
> => 2 solutions
> - We just forbid synchronous circular calls in our system (because it just
> doesn't work with Glib binding, as you mentioned).
> - We allow them but we need to inform the developers that their service can
> be called from different threads (your JAVA binding model) so they have to
> be very carefull with their thread synchronizations. Actually, they need to
> be aware that a call they might perform on an external component might end
> up in a call on their own service, but this call will be handled by a
> different thread...
> 
> Any of these solutions would lead to a much more complex system.
> It seems like DBus has really been designed for very simple communication
> between desktop apps but it's really not recommanded if you want to build a
> complex system.
> 
> Is that right ?
> 

I've copied this to the mailing list so that others can hopefully
explain this better than I.

I think the basic idea was that even with this system you will have
concurrency and reentrancy issues, but most people will assume they are
solved and ignore them. The resultant bugs will be more subtle and not
caught early on. If developers know that they have to deal with them,
then they will do so properly and those subtle bugs will not arise.

In the case of the Java bindings I am explicit about this. Java
developers are used to using blocking IO, multiple threads and dealing
with synchronization issues in all large programs and so this will not
be a surprise to them. I explicitly say in the documentation "These
methods are called in their own threads asynchronously, you will have to
deal with the concurrency."

Matt

--
www.matthew.ath.cx
D-Bus Java
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070322/1ba74370/attachment.pgp