fast path for local D-Bus calls

[Havoc Pennington]

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.

Havoc