Bit of background: In Unix, new users soon learn about the "kill" command. Then, after a while, they learn that kill doesn't always work.
Then, after that, they learn about "kill -9", which does (almost) always work.
Thereafter, they never use anything other than "kill -9"; they assume that
is the default command. Why use anything else? (rhetorical question!)
With that said, I've recently started playing around with "TASKKILL" under Windows. I tried to kill something without using /F and it gave error messages that it couldn't kill it and that I should use /F. I re-tried
with /F and it killed it as expected.
So, my questions are:
1) What exactly does /F do (in technical terms) that it doesn't do w/o /F?
2) It there any (practical) reason not to always use /F?
Bit of background: In Unix, new users soon learn about the "kill" command. Then, after a while, they learn that kill doesn't always work.
Then, after that, they learn about "kill -9", which does (almost) always work.
Thereafter, they never use anything other than "kill -9"; they assume that
is the default command. Why use anything else? (rhetorical question!)
With that said, I've recently started playing around with "TASKKILL" under Windows. I tried to kill something without using /F and it gave error messages that it couldn't kill it and that I should use /F. I re-tried
with /F and it killed it as expected.
So, my questions are:
1) What exactly does /F do (in technical terms) that it doesn't do w/o /F?
2) It there any (practical) reason not to always use /F?
So, my questions are:
1) What exactly does /F do (in technical terms) that it doesn't do w/o
/F?
2) It there any (practical) reason not to always use /F?
So, my questions are:
1) What exactly does /F do (in technical terms) that it doesn't do w/o
/F?
2) It there any (practical) reason not to always use /F?
In article <u9air3$2j5vr$1@dont-email.me>, R.Wieser <address@is.invalid> wrote:
Kenny,
So, my questions are:
1) What exactly does /F do (in technical terms) that it doesn't do w/o >>> /F?
2) It there any (practical) reason not to always use /F?
The takeaway that I am getting from the responses on this thread is:
1) With /F, it does an actual kill, in the same style as what I am used
to on Unix.
2) Without /F, it really doesn't do a kill at all. It just send a
WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
actually is), asking the app to do a normal exit.
I never understood the point of case 2 above, but that does seem to be the general mindset of the people who program GUI/"end-user" OSes. Always do
it the complex way first... (Yes, I do get what some of the responses have said about it being handy when the system is shutting itself down, but it doesn't seem ot me to be particularly ideal when the user is explicitly invoking a "kill" functionality)
My personal mindset is that if we are at the point of using a task killer to kill processes, we've already given up on a "graceful" shutdown. If the
app was still in a state where it makes sense to try for a graceful
shutdown, I'd just use the app's own machinery (menu
option/hotkwy/whatever) to do it. The fact that I'm using the kill program to do it, indicates we're already past that stage.
Anyway, thanks for the responses. I think we can consider this closed.
2) Without /F, it really doesn't do a kill at all. It just send a
WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
actually is), asking the app to do a normal exit.
I never understood the point of case 2 above,
Kenny,
2) Without /F, it really doesn't do a kill at all. It just send a
WM_QUIT (Or WM_CLOSE - some lack of clarity as to which one it
actually is), asking the app to do a normal exit.
I never understood the point of case 2 above,
The difference is that when you /ask/ a process to terminate itself you give it a chance to cleanup after itself (close files etc.), while the "/F" just tells the OS to remove the process from its tasklist and free its memory.
IOW, if the process had data it didn't write/update (to file or other) than that data is lost* - possibly causing problems later on.
*same as shutting down the 'puter using the "hold the power button 5 sec." way - or yanking an USB (thumb)drive instead of asking the OS to eject (unmount) it first.
Regards,
Rudy Wieser
Just because a process becomes unresponsive to user input (keyboard or
mouse) does not mandate it is also unresponsive to a WM_CLOSE request.
I've had "dead" programs that I cannot use the keyboard or mouse to
control, but taskkill will still works to get the program to gracefully >close, like write its buffers instead of losing that data. *IF* you can >still use the keyboard or mouse in the program then you should also be
able to use the incorporate exit routine in that program, which also
means you wouldn't be trying to taskkill at all. If you are trying to
use taskkill, user input isn't available with the program, but the
program might still respond to a WM_CLOSE request. So, you first try to
exit using the program, if that fails then taskkill, and if that fails
then taskkill /f.
Interestingly enough, the specific app in question will mis-behave if
it is shutdown "normally" or killed w/o /F. Only killing it via /F
ensures a proper shutdown. Funny that.
And, no, I don't have the source code for the app.
In article <o94iqrlqg7ap$.dlg@v.nguard.lh>, VanguardLH <V@nguard.LH> wrote: ...
Just because a process becomes unresponsive to user input (keyboard or
mouse) does not mandate it is also unresponsive to a WM_CLOSE request.
Point taken, although in Windows, it is usually all or nothing.
The list of actions to take is much shorter than in Unix and for most
people, most of the time, a fast harsh kill as the first thing to try is generally reasonable.
I've had "dead" programs that I cannot use the keyboard or mouse to
control, but taskkill will still works to get the program to gracefully
close, like write its buffers instead of losing that data. *IF* you can
still use the keyboard or mouse in the program then you should also be
able to use the incorporate exit routine in that program, which also
means you wouldn't be trying to taskkill at all. If you are trying to
use taskkill, user input isn't available with the program, but the
program might still respond to a WM_CLOSE request. So, you first try to
exit using the program, if that fails then taskkill, and if that fails
then taskkill /f.
Interestingly enough, the specific app in question will mis-behave if it is shutdown "normally" or killed w/o /F. Only killing it via /F ensures a proper shutdown. Funny that.
And, no, I don't have the source code for the app.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 307 |
Nodes: | 16 (2 / 14) |
Uptime: | 107:23:26 |
Calls: | 6,852 |
Calls today: | 3 |
Files: | 12,355 |
Messages: | 5,415,942 |