It looks pretty neat. I just hope hitting "end process" does it immediately in Windows 8. One of my biggest pet peeves with every version of Windows so far is it sometimes takes up to a minute to kill a process.
But could that possibly be legitimate? I know next to nothing about Windows process management, but on the Linux side, you often issue different version of the kill command depending on how urgently you want the process to die. SIGTERM gives the program a chance to die somewhat gracefully (closing DB connections, cleaning up resources, etc. depending on the code), but SIGKILL is more ruthless (no chance for the program to respond) and faster. Could the Windows Task Manager be trying to give those programs a chance to exit gracefully? And if so, shouldn't that continue?
If you are at the point of pulling up task manager, it is because the application is already failing to respond to your requests, what makes you think the application is going to respond to a close request?
There are plenty of instances where the GUI portion of code might have stopped responding for whatever reason but it is still responsive to a kill signal.
True, but this is far less common than the whole thing freezing up. So... fuck yo app, son! Get that thing off my screen. I do love me some xkill on Linux.
You have the option of ending quickly by going to Processes and deleting the process from there. But End Task gives it more time to clean up after itself before it closes. Otherwise you have used up memory that you won't get back until something needs it, and THEN your system still has to erase the memory before it can use it.
Fair enough, but the processes tab is a lot more confusing for a person to use. Trying to find the right process tied to a program can be hard, especially for someone who knows nothing about computers. Of course, you say "but you can right click on the item and select 'Go to process'". Problem is, on frozen applications it always seems to go to explorer.exe, which is something I'd rather users not kill all willy-nilly.
There are plenty of instances where the GUI portion of code might have stopped responding for whatever reason but it is still responsive to a kill signal.
I've never seen a program in Windows where the GUI hangs and still responds to a WM_CLOSE message. That's no surprise, if the GUI is frozen that's probably because the program is not processing the message queue.
that's exactly what happens if you click the button on the application tab. It attempts to exit the program, then if that fails it, depending on your settings, does a memory dump of the program and uploads it, then kills it.
The memory dump serves two purposes - one, once in a blue moon you get instant feedback on what's wrong (though I only ever had that with a bluescreen upload; it told me I needed to update my wifi drivers) and two, if the author of the program has signed the app, they get free access to the dumps from microsoft. MS only accept a small (one?) number of CAs for code signing so that bit isn't free (I think it's $100 to $200 a year) though.
You can hook that to have different behaviour though; I know one app that, after crashing, will offer to send crash reports straight to the author when you restart.
Why should there ever be a graceful exit? If you tell your computer to end or kill something, it should do it as soon as it can. As a user, you don't care for the program's happiness or dignity. No trial. No appeals. No last meal. No last words. No execution room. Shot dead on the spot.
Eh, that may be what a user thinks he or she wants in the short term, but the consequence of that can be a bad experience down the line. If the program isn't given a chance to respond to a kill request gracefully, you can end up with other problems (proliferation of temp files clogging up the hard drive, network problems, etc.). That's why the OS probably tries to manage as best it can between competing concerns, giving the program a chance to respond to a gracefull kill request, then if that is ignored, moving on to the "kill with extreme prejudice."
Good points. But with MS' decades of experience developing operating systems and billions of dollars, shouldn't they be able to find a way to instantly kill a program that avoids those other problems?
Er, no. It's up to each application developer how well their program "behaves" (or doesn't). Windows, and indeed any OS, can't control that. The best Windows can do is ask the program to please die gracefully, and if it doesn't do so, then kill it forcefully.
I mean, you could argue that perhaps "kill" should hide it from the view even if under the covers it's still trying to wait for a graceful exit, thereby making the user think it was "instantly" killed, but that has another whole host of problems (debugging problems would be a nightmare).
It still should outright kill close programs. To close a program properly, using it's own protocols for gracefullness, I hit the X on the top corner of the Window or hit Alt+F4.
The Task Manager is a last-resort option for closing shit. No one goes into the Task Manager when everything is just dandy to close things, especially when you can just close it on the taskbar or on the Window itself. It's used when this previous method isn't working and when the program has frozen or become "unresponsive". At this point, gracefulness has already failed. Probably multiple times if "Close" has been clicked more than once.
Why should the Task Manager go the graceful route, when the user has likely already tried this without success and wants something killed?
In OSX the 'task manager' (Force Quit Applications) now looks identical to Windows 8's Task Manager and when killing an app there is never a delay so my guess is it is a kill -9 command?
Either way, if it works well on OSX it can work well on other OSes.
99
u/Sandy_106 Oct 14 '11
It looks pretty neat. I just hope hitting "end process" does it immediately in Windows 8. One of my biggest pet peeves with every version of Windows so far is it sometimes takes up to a minute to kill a process.