connection lost: pending method calls not notified
Submitted by Patrick Ohly
Assigned to D-Bus Maintainers
SyncEvolution started to use D-Bus as IPC mechanism between processes, using a direct D-Bus connection. One of my tests fails when using libdbus: when the peer goes down and the connection is closed, the surviving processes doesn't get an error callback for its pending method calls on that connection.
This only matters when "exit on connection loss" is disabled. SyncEvolution disables that because it needs to clean up resp. continue syncing when possible without the peer.
It works when using GIO D-Bus, which is the long-term solution for SyncEvolution - except on systems which only have libdbus.
I tracked it down to the following sequence of events (1.4 branch):
- connection loss is noticed
- connection_timeout_and_complete_all_pending_calls_unlocked() queues pre-generated error messages ("timeout_link") and removes the pending method call.
- dbus_connection_dispatch() is called and processes the queued error messages. Because there is no pending method call matching the reply anymore (it was removed in the previous step), the message is dropped as "not handled".
I'm not sure what the right solution is. Keep canceled method calls? Perhaps in a separate list?
Can anyone think of a workaround? I'd like to get SyncEvolution working on legacy Linux distros which won't get libdbus updates.