service-side: replies from standard or unimplemented interfaces "jump the queue"
Submitted by Simon McVittie
Assigned to David Zeuthen
Link to original bug (#726259)
Description
To reproduce:
service-side
- have an object that exports interface A, but not interface B
- implement the method A.M to return a result as quickly as possible
client-side
- call A.M
- call B.M2 or Introspectable.Introspect()
Expected result:
- reply from A.M is received before error reply from B.M2 or successful reply from Introspectable.Introspect()
Actual result:
- reply from B.M2 or Introspect "jumps the queue" and is sent immediately, whereas A.M is processed in an idle
The standard Peer interface behaves the same, but that's not necessarily unexpected, because Peer is already weird.
If the object does not reimplement Properties, bits of it behave similarly.
If GDBus consistently used schedule_method_call() to implement every method call, then the order would remain consistent. I think consistency is more important than optimization for these interfaces, which are not fast-path stuff - the slower path has to be taken anyway for the actually-useful code, like calls to methods that have a non-trivial implementation, or getting the properties of interfaces that have them.
This is pretty annoying in Telepathy, which I'm currently trying to port to GDBus. Our regression tests sometimes make a dummy method call which propagates through the client stack, across dbus-daemon, through the service stack and back to the client, so that they can assert that every message that should have arrived has arrived, and messages that should not have arrived have not. In telepathy-glib, we used Introspect() for this; similarly, in connection managers and Mission Control, we used calls to interfaces that don't exist. In both cases, dbus-glib went through the same dispatching sequence either way, but because GDBus "jumps the queue", we will now have to use a separate, appropriately-chosen dummy method for each object.
Version: 2.39.x