DBusServer accepted client close

[Simon McVittie]

On Fri, 05 Oct 2018 at 09:52:43 +1300, Lawrence D'Oliveiro wrote:
> On Thu, 4 Oct 2018 17:10:06 +0800, Andy Green wrote:
> > When I create the connection using eg gdbus, stuff
> > that I allocate that I want to associate with the connection, has no
> > obvious event on which it can be deallocated because the connection
> > has ended.

It depends what you consider to be "the end": the point when the
connection has disconnected, or the point when there are no more
references to the object in memory?

> How about setting a DBusNewConnectionFunction on your DBusServer object
> <https://dbus.freedesktop.org/doc/api/html/group__DBusServer.html#gaa14d9109e04adccffd9a40460c28c53b>
> which calls dbus_connection_set_data to set some dummy data together
> with a DBusFreeFunction
> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga845b4942399f43dd4ac644de7cb9e3ff>.
> Then when the free function is called (without you doing a
> dbus_connection_set_data again on the same slot), then you know the
> connection is going away.

That tells you when the connection has no more references. Sometimes
that's what you want, but you do have to be careful not to create cyclic
references that would keep the DBusConnection object in memory forever.
Its primary use is to associate some state with a connection that will
be freed eventually: for instance you might attach details of the client,
like resources it has allocated in your server, to the connection so
that you can easily deallocate them when it goes away.

The other possible end point for a DBusConnection is when it has
disconnected - the equivalent of read() or recv() returning 0 bytes
(the end-of-file indicator) on a pipe or socket. libdbus guarantees
that disconnection will be signalled by a special fake message being
"received" by the connection, as though it had come from the client:
it's a signal message (DBUS_MESSAGE_TYPE_SIGNAL), with object path
DBUS_PATH_LOCAL ("/org/freedesktop/DBus/Local"), interface name
DBUS_INTERFACE_LOCAL ("org.freedesktop.DBus.Local"), and member name
(signal name) "Disconnected". The special message is queued, filtered and
dispatched like any other message you could receive. However, its object
path and interface name are reserved, and clients cannot successfully
send them (if they try to, they'll get disconnected), which means you
can know that the special message really came from libdbus.

The canonical example of a DBusServer is the dbus-daemon, which
makes use of both those mechanisms. For the data slot, search
for connection_data_slot in bus/connection.c. For the special
disconnection message, look for DBUS_INTERFACE_LOCAL in bus_dispatch(),
in bus/dispatch.c.

Other D-Bus APIs have different equivalents of one or both of those.
For instance, GDBus can attach arbitrary data to a GDBusConnection with
g_object_set_data() (which is similar to dbus_connection_set_data()),
but it signals connections being closed via the GDBusConnection::closed
signal, rather than by "receiving" a fake message.

    smcv