On Wed, 26.11.14 10:10, Thiago Macieira (thi...@kde.org) wrote: > On Wednesday 26 November 2014 12:35:33 Lennart Poettering wrote: > > > Aside from the connection-control mechanisms (AddMatch, RemoveMatch), did > > > you see any problems? > > > > It was primarily about that, but it is easy to construct races with > > this for most of the other driver calls as well. > [snip] > > Can you explain, if you remember, how the race could happen for the other > driver calls? > > Is this one: GetConnectionUnixProcessID could return stale information > because > the process has exited by the time that the reply arrived. If so, this race > already existed in dbus1.
Here's are two examples: First: AcquireName(): you issue issue an async request for acquiring "foo.bar", and immediately send a message to it. On dbus1 this will work: the bus will first process the AcquireName(), and then deliver the message back to you given that you now have the name. In a kdbus design with an extern driver process the AcquireName() call would be passed to the driver, and the next message most likely be processed before the driver processes it, thus most likely resulting in a delivery failure of the second message. Now, that's the reason why acquirename/releasename need to be implemented client side. With that knowledge we can punch holes in the other calls too. For example, the GetConnectionUnixProcessID() call you brought up: let's now issue a GetConnectionUnixProcessID() async first, immediately followed by an AcquireName() for the same name. On dbus this will tell you the old owner, and then acquire the name for you. On kdbus with an external driver this would be different though. While the GetConnecitonUnixProcessID() is queued and waiting to be processed the AcquireName() might already have been executed (because it needs to be an ioctl as we have shown above), hence you would get your own PID returned, not the old one! hence, this calls really should be sync local ioctl()s, not half-half... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel