Messages in this thread | | | Date | Wed, 29 Apr 2015 18:34:18 -0400 | From | "John Stoffel" <> | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 |
| |
>>>>> "Austin" == Austin S Hemmelgarn <ahferroin7@gmail.com> writes:
Austin> On 2015-04-29 14:54, Andy Lutomirski wrote: >> On Apr 29, 2015 5:48 AM, "Harald Hoyer" <harald@redhat.com> wrote: >>> >>> * Being in the kernel closes a lot of races which can't be fixed with >>> the current userspace solutions. For example, with kdbus, there is a >>> way a client can disconnect from a bus, but do so only if no further >>> messages present in its queue, which is crucial for implementing >>> race-free "exit-on-idle" services >> >> This can be implemented in userspace. >> >> Client to dbus daemon: may I exit now? >> Dbus daemon to client: yes (and no more messages) or no >>
Austin> Depending on how this is implemented, there would be a Austin> potential issue if a message arrived for the client after the Austin> daemon told it it could exit, but before it finished shutdown, Austin> in which case the message might get lost.
What makes anyone think they can guarrantee that a message is even received? I could see the daemon sending the message and the client getting a segfault and dumping core. What then? How would kdbus solve this type of "race" anyway?
Can anyone give a concrete example of one of the races that are closed here? That's been one of the missing examples. And remember, there's no perfection. Even in the kernel we just had a discussion about missed/missing IPIs and lost processor interrupts, etc. Expecting perfection is just asking for trouble.
That's why there are timeouts, retries and just giving up and throwing an exception.
John
| |