GNOME Bugzilla – Bug 144557
Force Quit timeout is too short
Last modified: 2004-12-22 21:47:04 UTC
Force Quit timeout is too short in those cases when a large application is mostly swapped out. It may well take 20 seconds or more for it it get swapped in. This happens in particular when ending a gnome session, when the system tries to simultaneously exit and hence swap in every application. A suitable timeout might be on the order of 30 seconds. I'm not familiar with details of the mechanism so I may be missing something, but the bottom line is that most of the time when I get the "Force Quit" dialog it's a false alarm.
it's sort of a fine line; wait too long and the dialog become useless. By the time 30 seconds have passed I've already fired up the gnome-system-monitor and killed the application manuall. Besides, while the application is exiting it should still respond to _NET_WM_PINGs, and to do so requires swapping in just one page. And it's the same page for all the apps using a given toolkit. It shouldn't be a problem unless there's an application bug that causes it to synchronously perform some complex operation on application exit.
Your rationale of the application needing to only swap in one page sounds convincing. Unfortunately what you say doesn't match with what I'm seeing. I just made a test: on my 500 MB RAM box, I created a 5000x5000 picture in gimp, allocated some more memory with perl -we '@a = (1 .. 4000000); sleep 1000', watched gimp getting almost completely swapped out. Then I simultaneously exited gimp and my 100 MB firefox, and sure enough I got the "force quit" dialog. Now you could argue that my test was contrived, and I would agree, but at least it seems to defeat the argument that only one page needs to be swapped in and that's always going to happen quickly.
At one point we had decided to make this slightly longer, I don't remember if we checked in the change. 30 seconds seems too long. At some point I think we do have to say "if your system's performance is hosed, this is one of the negative side effects, run less software or buy more hardware" Maybe a better fix would be to close the dialog again if the ping reply comes in while the dialog is up. Kind of weird, but might be right anyway. Perhaps change the dialog to "this application was not responding, but now it is. nevermind." when we get the ping reply ;-)
This long delay isn't always due to insufficient hardware. I often leave, or forget, large applications on the background for days, and paging 500 megs in is slow no matter what. Follows an IMO realistic use case. Pan the news reader grows almost boundlessly with large newsgroups. You load a large newsgroup, so pan becomes 500 megs, then access smaller groups for a few days, and the unnecessarily allocated 500 megs gets swapped out. Then you quit pan and it starts paging in the 500 megs, and that takes time. You wait for 10 seconds during which all but pan gets swapped out. Then you decide to quit also a big gimp to free some more memory, and change to gimp's virtual desktop. Paging gets twice as bad, and Force Quit appears. Regarding the reaction to the application answering again, perhaps in that event add to the dialog text "The application is answering again. This dialog will be closed shortly.", then wait for maybe 4 seconds and close the dialog. I think that, or just closing the dialog immediately if the application replies, is the right thing to do. As an aside, I notice that trying to close an application in stopped state trigges Force Quit. It would seem more sensible to me to tell the user that the application is stopped. It may be hard for a beginner to realize he has by mistake stopped and application, fe. when it has been started from shell and he has pressed ^Z, usage of which he hasn't yet mastered.
*** This bug has been marked as a duplicate of 121934 ***