Proxy Objects & Interfaces In DBussy
Simon McVittie
smcv at collabora.com
Wed May 24 12:32:40 UTC 2017
On Wed, 24 May 2017 at 23:26:34 +1200, Lawrence D'Oliveiro wrote:
> Then, from this you get the proxy interface with
>
> iface = obj.get_interface(«interface_name»)
>
> This is the point where D-Bus traffic occurs to introspect the actual
> proxy interface object.
I consider this to be a design flaw in dbus-python: it does far too much
introspection-guided guessing at what the client author meant, with the
result that if the Introspect() result differs from what the client author
was expecting, they will get weird TypeError exceptions that do not
reflect what the actual D-Bus type mismatch is.
Relying on introspection also adds extra, hidden method call round-trips,
which have a measurable impact on performance (demonstrated in Will
Thompson's experiments with removing introspection from telepathy-gabble's
automated tests).
If Introspect() is called synchronously, like any other synchronous method
call it will block the main loop, and can result in message re-ordering[1],
which in the worst case can break the intended semantics of D-Bus APIs.
Introspection is mostly a development and debugging feature, and ideally
nothing would rely on it at runtime. It's at least a decade too late for
dbus-python to break backwards compatibility in that way, but hopefully
it isn't too late for DBussy.
S
[1] http://smcv.pseudorandom.co.uk/2008/11/nonblocking/
More information about the dbus
mailing list