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

[Simon McVittie]

On Mon, 18 Dec 2006 at 14:10:02 -0500, John (J5) Palmieri wrote:
> 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).

OK, since you've brought it up, I'll mention why this won't quite
have the efficiency of a local call:

If you do a remote call to yourself (with no shortcutting), the
marshal+unmarshal step has the result of deep-copying all objects. This
means that if the called function mutates its arguments, those changes
are thrown away. Compare with passing a dict or list to a function by
reference via a real local call, where the changes take effect in the
caller too.

Also, if you do a remote call to yourself, the marshal+unmarshal will check
types and normalize where necessary (you can pass any sequence where an array
is expected, and it'll always be an Array at the other end).

The simplest way to make the semantics match would be for a fast-path
D-Bus call to construct a Message and pass it straight to the message
handler without going via the bus daemon. This carries out the marshal
and unmarshal steps, but bypasses the send/receive and the context
switch between Python and the bus daemon.

Sadly dbus_connection's public API doesn't have a "push_message", so
to implement this I'd also have to make the interface between dbus-python
and main loops more complex than it currently is. As a result I don't
think this is something for 0.80 - I'd like to get 0.80 to a final
release with the current simplistic mainloop API, then revisit main
loops for some later version (which I need to do anyway for pure-Python
main loop support).

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.

	Simon