fast path for local D-Bus calls

Havoc Pennington hp at
Mon Dec 18 12:02:26 PST 2006

Simon McVittie wrote:
> Oh, also: it occurs to me that if blocking local calls get a fast-path,
> then the method implementation will run in whatever thread is blocking,
> whereas in a true remote call the method implementation will run in the
> mainloop thread. The issues are similar to those raised if we have
> blocking calls re-enter the main loop.

If we did a fast path I'd do it by by essentially moving the message 
from the head of the outgoing queue to the tail of the incoming queue 
when doing the read_write step. Then the semantics seen by the app don't 
change and there is no new reentrancy introduced.

However, the overall semantics do change, for example now dbus-monitor 
can't see the message.

On a more pragmatic level, I think DBusConnection, threads, reentrancy, 
and the read_write/dispatch loop are at something of a complexity limit 
where it's already very hard to understand; I'm a little reluctant to 
make it worse, in particular with code that tries to guess whether a 
message would be routed locally by the bus daemon.

The dbus design certainly reflects a point of view that "network 
transparency" is a poor design choice, and I'd tend to think we should 
just stick with that.

The way bindings are supposed to work is that you have a plain local 
non-networked object, and you can wrap it in a proxy object that exports 
the local object over the network. But when working locally, you are 
supposed to just use the local object normally.


More information about the dbus mailing list