D-Bus is killing me

[John (J5) Palmieri]

On Mon, 2006-12-18 at 03:43 +0000, Simon McVittie wrote:
> On Mon, 18 Dec 2006 at 02:15:48 +0000, Mystilleef wrote:
> > I figured the concepts were the same and I didn't want to write yet
> > another D-Bus for intra-process communication specifically for my app.
> 
> Sorry, my use of the term "intra-process" may have been somewhat unclear.
> I should have said "within the same process". Within a single process you
> don't need D-Bus, you can just call functions/methods directly; if you're
> putting effort into making sure there is only ever a single process for
> your app (as you seem to be), then it's guaranteed that any "instance" you
> want to communicate with is in-process, so you never need to make calls to
> other instances that *aren't* in-process and everything is simple.
> 
> (By "instance" I assume you mean an instance of some particular object,
> like a window or a document? I'd just have a global list of windows...)
> 
> You can still provide a D-Bus interface if you want, for other processes
> to use, but using that to communicate with other "instances" within the
> same process is unnecessary.
> 
> D-Bus doesn't distinguish between in-process and out-of-process, and
> this is why making in-process calls via D-Bus is inefficient.
> Suppose your objects are document windows (class DocumentWindow, a
> subclass of dbus.service.Object), and they have a method
> EnterText() which you want to call. Here's what happens:
> 
> 	* Client marshals arguments into a message
> 	* Client sends message over UNIX socket to bus daemon
> 	* Bus daemon sends message over UNIX socket to service
> 	* Service (in which there is a DocumentWindow instance)
> 		unmarshals message and runs the actual method code
> 	* Service marshals reply (a second message)
> 	* Service sends reply over UNIX socket to bus daemon
> 	* Bus daemon sends reply over UNIX socket to client
> 	* Client unmarshals reply
> 
> In the case where the client and the service are the same process,
> exactly the same thing happens (although in practice you'd have to use
> async calls in this situation, because of the deadlock I mentioned in a
> previous mail - while the client part of the code is blocking on a
> method call, the main loop isn't re-entered and the service part of the
> code isn't run, unless you're using threads or something.)
> 
> However, if you know they're the same process, you can bypass D-Bus
> completely: just call the EnterText() method on the DocumentWindow.
> This is rather more efficient - no marshalling, no unmarshalling, no context
> switches.
> 
> If dbus-python *did* distinguish between in-process and out-of-process
> calls, it could provide a fast path for in-process calls which did just
> call the EnterText() method directly. This seems unnecessary, since app
> authors should presumably have some idea what's in their process space,
> so we go for the simple approach and don't distinguish.
> 
> Also, in practice either the semantics would be subtly different, or the
> call would still have higher overhead than a true local call (converting
> arguments to canonical types and deep-copying lists, for instance).
> 
> The D-Bus language bindings try to make inter-process communication as
> easy as an in-process method call, but if you could just be making
> an in-process method call, it'll always be more efficient, and as easy
> or easier, to do that instead.

As much as I don't like the tone of the original message that was sent
to the list (welcome to bleeding edge development) there are some good
discussions that resulted.  I would ask the original poster to be more
productive and become a participant.  We are very accommodating. 

That being said I would argue for doing the in-process shortcutting
(along with perhaps a debug mode that will complain if you call into
yourself).  Qt4 bindings do this already and there can be instances
where a process loads another library which can call back into the same
process space.  Very unlikely but still it would be nice to keep pythons
strength of not being too strict.  In practise I see the biggest issue
being the lookup overhead which would be very negligible.
 
-- 
John (J5) Palmieri <johnp at redhat.com>