race-free exit-on-idle (redux)

[Simon McVittie]

On 14/05/15 10:06, Lennart Poettering wrote:
> On Wed, 13.05.15 16:03, Colin Walters (walters at verbum.org) wrote:
>> On Wed, May 13, 2015, at 02:27 PM, Lennart Poettering wrote:
>>> But it only works for services which do not create
>>> context objects based on method calls. 

This is a very important restriction. In practice, D-Bus services often
do create objects that are only guaranteed valid within the scope of a
unique name.

For instance, Telepathy has lots of those objects - channels,
connections, channel dispatch operations - and only a few objects that
are either stateless, or have their identities (object paths) persisted
to disk.

> In GDBus it is common to invalidate client side proxy objects
> when the bus services they wrap goes away.

dbus-glib and dbus-python too. I would go as far as to say that any
D-Bus binding that does not optionally do this invalidation is broken.
(It should be optional, because some objects are stateless or
persistent, but that isn't the common case.)

> BTW, kdbus solves this all properly, because it knows
> sd_bus_try_close() which will close the bus only if nothing is
> queued. 

Right. I don't think this can be solved in traditional D-Bus without
some equivalent cooperation between dbus-daemon and the service. I think
Ryan Lortie was also interested in solving this?

Something like:

Mark() -> empty message

(Service drains its incoming-message queue as far as the Mark() reply
and decides whether it still wants to shut down. If it does, then it
calls...)

TryClose(u: the serial number of the Mark reply) ->
    either: disconnect the service without replying (caller will get
        a Disconnected error and shut down gracefully)
    or: error "something else happened since then" and continue

You need Mark() because serial numbers are not globally unique, only
unique per (sender,recipient) pair - and possibly not even then if the
sender is malicious or incompetent - so the only sequence you can
necessarily trust is one provided by dbus-daemon itself.

The dbus-daemon could maintain state per application, updating it every
time a message was enqueued for sending:

* if the most recently enqueued message was the Mark() reply: its serial
  number
* else: 0

Or something.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>