Re: Session DBus protocol
- From: Matthias Clasen <matthias clasen gmail com>
- To: Ryan Lortie <desrt desrt ca>
- Cc: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Session DBus protocol
- Date: Mon, 25 Oct 2010 20:16:33 -0400
On Mon, Oct 25, 2010 at 4:01 PM, Ryan Lortie <desrt desrt ca> wrote:
> Vincent and I are sitting on a couch here at UDS reviewing the DBus
> protocol used by gnome-session.
> I am interested in adding support to GtkApplication.
> My biggest concern is that the "emit signal and wait 1 second" approach
> for checking which clients want to stop the logout from happening is
> really bad.
> 1) Some clients might miss the deadline (if they are swapped, or the
> system is really bogged down). Data loss here.
1 second is really a long time, if clients don't get around to
responding within that time, chances are the user will have
power-cycled the machine before they get around to responding...
Also note that clients don't really have to wait until the
QueryEndSession signal, they can just go ahead and place an Inhibitor
when they start whatever uninterruptible operation they are doing.
Finally, clients should not rely on save-at-session-end to prevent
data loss, anyway.
> 2) We may end up waiting for 1 second completely unnecessarily.
In reality, you are going to have all clients responses within a few
The 1 second timeout is really only going to trigger if you have a hung client.
> I was wondering if maybe we could improve this interface to work more
> like the following:
> 1) Clients that may want to block the logout register themselves with
> 2) gnome-session does a AddMatch on their NameOwnerChanged so it can
> tell if they exited (and unregister them).
> 3) At logout time, gnome-session makes a method call to each registered
> app and *waits for a reply*. The length of time to wait should be
> much longer than 1 second. Similar to the close button on
> unresponsive windows, we could pop up a "this application is stuck"
> dialog in that case allowing the user to kill it if they explicitly
> choose to (but never assuming that no reply equals "no data to
I fail to see any difference ?!
All this is already happening with the way things currently are...
] [Thread Prev