On 15/06/15 15:32, Lennart Poettering wrote: > Did I get this right, you have one bus connection per thread, but > possibly both a kdbus client and its service run from the server, and > you want broadcast msgs sent out from one to then also be matchable by > the other?
If this is indeed what eshark means, then "talking to yourself" like this is something that always used to work with traditional D-Bus (as long as you make sure to never block waiting for a reply!), so it's a regression if it doesn't work with kdbus. In traditional D-Bus, broadcasts go to any connection that has registered its interest in the broadcast via AddMatch. dbus-daemon does not discriminate between the sender of a message, and other connections - in particular, it will send a copy of a broadcast back to its sender, if that's what the sender asked for. Various projects' regression tests work like this: they run the client-side and service-side code in the same GLib main loop and do everything asynchronously, and it works. Ideally, the only processes involved are the test and the dbus-daemon (and under kdbus the dbus-daemon would not be needed either). > Can't you dispatch that locally? i.e. in addition to passing the msg > to kdbus also enqueue it locallly along the kdbus fd, or so? That would mean re-ordering the broadcast messages (taking them out of their correct sequence relative to other messages), which is one of the reasons why traditional D-Bus implementations don't optimize "messages to yourself" in this way. One of dbus-daemon's roles is to impose a total ordering on messages - it's the component that makes the arbitrary decision on how the individual message streams get interleaved. -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel