[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: improved Crash Dialog needed
From:       Ryan Cumming <ryan () completely ! kicks-ass ! org>
Date:       2002-08-24 9:07:07
[Download RAW message or body]

On August 23, 2002 22:05, Michael Peligro wrote:
> No worries here. Blinking colon is a very minor usability issue. I use the
> blinking visual cue apart from its intended purpose. It's just a usability
> quirk/practice on my part as a power user. It applies only to me. Either
> the KDE team defaults to make the colon blinking or not, doesn't really
> matter much, as long as they leave users with the option to make it blink
> or not.
Okay, cool :)

> Yes, I did run into instances when the display freezes but the other
> services are okay (e.g. NFS or Samba).
These cases are pretty hopeless

> Any suggestions on how we can intercept/anticipate a UI freeze? Is it easy
> to do this in KDE? We know that some freezes are beyond KDE to handle, but
> at least, we should make sure that whenever a freeze happens in KDE, a
> dialog will pop up and inform the user what to do
Okay, here's my plan:
We start a tiny, non-KDE daemon. This daemon would be sort of a watchdog, 
waking up every few seconds to make sure the computer is all right. This 
would involve checking if any process has obviously "run away" to the point 
of making the computer unresponsive. "Run away" could be defined as a process 
using an unreasonable amount of memory and/or CPU time, when other programs 
are obviously contending for those resources. 

If the computer isn't okay, we pop up a dialog. This dialog would give the 
user the option of terminating the application, or ignoring the potential 
problem. See http://completely.kicks-ass.org/watchdog-mockup.png for an idea 
of what that dialog could look like.

This is one case where the devil is definitely in the details. The daemon, 
dialog, and X-server would be susceptible to the same resource drain that is 
affecting the rest of the computer. One solution would be for the daemon to 
run at a realtime priority, with all of its memory mlock()'ed in place. When 
it encountered a potential trouble process, it would immediately SIGPAUSE it. 
This should (temporarily) relieve the resource contention that the process 
was causing, allowing the computer to become at least somewhat responsive 
again.

At this point the daemon would launch the dialog process with an elevated 
priority (nice level of -19). Depending on the result of the dialog process, 
the realtime daemon will either SIGCONT the process and allow it to continue, 
or SIGKILL in to oblivion.

Comments?

-Ryan
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic