Re: The future of session management in GNOME

[Brian Nitz <Brian Nitz Sun COM>]

Tommi Komulainen wrote:
> On 9/13/06, Brian Nitz <Brian Nitz sun com> wrote:
>   
> > Why do we ever log out?
> >     4) Free up resources.   ???
> >
> > Reason 4 is especially interesting for multiuser systems, especially
> > thin clients.  It might be interesting for embedded uses of GNOME
> > (laptop/child, maemo...) to reduce resources when user isn't looking.
> >     
>
> For single user embedded case I can't suddenly think of anything
> logging out would provide that idle/screensaver mode and offline mode
> wouldn't. When the user isn't watching you should've already stopped
> all timers and screen updates. Except for possible music playing and
> network transfers, when the screen is blanked nothing should be
> happening.
>   
I agree, what I'm proposing is a unified method of using "I'm not 
present" information to stop timers and screen updates instead of 
logging out.

For embedded you have control over timers and screen updates, but my 
guess is that maemo has their own solution and OLPC has another one and 
multiuser yet another.  For desktop and laptop PCs you  can invoke the 
kernel's power management to save the state of the entire machine 
(rather than the session), but this doesn't work for multiuser.
> Also doing more work (saving state, shutting down applications) just
> to do more work later (restarting the apps, restoring state) might not
> be the brightest idea unless you know the extra memory would be better
> spent elsewhere (but where? nothing should be happening when the user
> isn't looking.)
>   
Yes.  That's why I was considering a way of avoiding logout and yet 
avoid consuming resources when the user isn't present. But now that I 
look at it, when the screen is blank and I have terminal, evolution and 
a few other apps running, only at-spi-registryd and mixer_applet2 appear 
hot enough to be worth bothering about.  Memory usage while idle is a 
more significant issue.  In multiuser its obvious where the extra memory 
would be used.  In embedded its more a matter of reducing power 
consumption by avoiding cache misses to flash or disk.  But if the 
kernel is doing it's job, memory from idle user processes should be 
paged out, so I think we're better off attacking that problem by 
reducing general bloat rather than introducing page/swap complexity into 
the session manager.