On Wed, Apr 29, 2015 at 1:15 PM, David Lang <da...@lang.hm> wrote: > On Wed, 29 Apr 2015, Andy Lutomirski wrote: > >> On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn >> <ahferro...@gmail.com> wrote: >>> >>> On 2015-04-29 14:54, Andy Lutomirski wrote: >>>> >>>> >>>> On Apr 29, 2015 5:48 AM, "Harald Hoyer" <har...@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 >>>> >>> Depending on how this is implemented, there would be a potential issue if >>> a >>> message arrived for the client after the daemon told it it could exit, >>> but >>> before it finished shutdown, in which case the message might get lost. >>> >> >> Then implement it the right way? The client sends some kind of >> sequence number with its request. > > > so any app in the system can prevent any other app from exiting/restarting > by just sending it the equivalent of a ping over dbus? > > preventing an app from exiting because there are unhandled messages doesn't > mean that those messages are going to be handled, just that they will get > read and dropped on the floor by an app trying to exit. Sometimes you will > just end up with a hung app that can't process messages and needs to be > restarted, but can't be restarted because there are pending messages.
I think this consideration is more or less the same whether it's handled in the kernel or in userspace, though. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
