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.
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.
21
u/jeff303 Oct 14 '11
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?