[systemd-devel] [RFC][PATCH] sd-bus: split ref-counting of queues from ref-counting of the rest of the sd-bus object

[David Herrmann]

Hi

On Sun, Mar 23, 2014 at 4:49 PM, Tom Gundersen <teg at jklm.no> wrote:
> Introduce a new ref-count, n_ref_queues, which only protects the {r,w}queue of
> a bus, and introduce bus_{un,}ref(), which are only available internally, and
> which do not protect these queues.
>
> Make sure that sd_bus_message object do not call sd_bus_ref(), but only the
> internal bus_ref(). This is ok as the {r,w}queues should never be accessed via
> the message object (as doing so would anyway not be thread-safe).
>
> When the refcount on the queues reaches zero (even thought the refcount on the
> bus itself may not, due to references held by messages in the queues), the
> queues are flushed and their messages unref'ed. This avoids problems due to
> mutual references between busses and their queued messages. In particular we
> don't get an sd_bus_unref() -> sd_bus_message_unref() -> sd_bus_unref()
> call-chain.
>
> Moreover, we can now enforce that sd_bus_{un,}ref() is only ever called from
> the same thread as created the bus (whereas bus_unref() may be called from a
> different thread, as part of unref'ing a message being handled in a worker
> thread).

Code looks good and it should work this way. But as I said earlier,
I'd prefer if we could avoid dual-refcounts and instead take the refs
on the object we _actually_ want. Messages don't need the ->bus
pointer at all except for memfds, as far as I can see. So instead of
introducing a circular dependency bus->m->bus, why not take a
reference to the kdbus FD instead? Either by dup()ing the fd or
extracting it to a separate struct/refcount. We can still take an
sd_bus argument in message allocations, but just avoid ref'ing them.

With the current approach, m->bus becomes a pseudo reference as it's
not equivalent to real references. If we forced messages to be
referenced on the bus they're queued on, we could fix this more
easily, but we don't have this requirement. Therefore, I really wonder
whether keeping m->bus is making anyone happy?

Anyhow, I wanna hear first what Lennart had planned with m->bus..
maybe he can shed some light on this.

Thanks
David