fast path for local D-Bus calls
hp at redhat.com
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