On Wed, Apr 29, 2015 at 1:15 PM, David Lang <david@xxxxxxx> wrote:
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
Depending on how this is implemented, there would be a potential issue if
On Apr 29, 2015 5:48 AM, "Harald Hoyer" <harald@xxxxxxxxxx> 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
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.