fast path for local D-Bus calls (was: D-Bus is killing me)

John (J5) Palmieri johnp at redhat.com
Mon Dec 18 16:54:50 PST 2006


On Mon, 2006-12-18 at 22:00 +0000, Matthew Johnson wrote:
> On Mon, 18 Dec 2006, John (J5) Palmieri wrote:
> 
> > I was thinking of shortcutting before creating the message where you
> > check the dest against an internal list of owned names and call the
> > method directly in which case the only overhead is the lookup. One thing
> > I forgot about is you can pass the message into the exported method in
> > which case this would not work.  Havoc also has some compelling
> > arguments for knowing when you are doing remote calls.  Of course there
> > are those like Avahi who want to totally mask these things.  Perhaps in
> > any case we should have the lookup and error out appropriately when
> > someone calls a name within their own address space.  We have the info
> > to even suggest calling the method directly.
> >
> Also, don't forget this only solves the direct-re-entrancy case. People
> still need to be aware when a blocking call to another process could
> cause a method call back to you. It may be worth leaving this as is so
> that people don't get too complacent and forget the other re-rentrancy
> case.

But having the warning there is actually good.  I have yet to run into
someone calling back into themselves from another process who didn't
understand this was bad design and wouldn't change their app.  I have
run into issues where people just can't believe that using an IPC
mechanism to call into ones self is a bad idea.  Having the error
message points people in the right direction.  If we are worried about
the lookup overhead we could just have a dbus.set_debug_mode() call. It
would be nice if we can do this for the remote case and in fact we
should be able to at least flag potential issues with external tools
like dbus-monitor (though there is no way to know if we are still in a
dispatch we can track message chains to see if an app is called before
it receives a reply). I think anything to help pinpoint issues is good
whether or not it is the apps or D-Bus' fault.

-- 
John (J5) Palmieri <johnp at redhat.com>



More information about the dbus mailing list