Tim Peters <tim.one@comcast.net> writes: > > That sounds like FUD. > > Argue w/ Microsoft -- you've read their docs. Apparently not the ones you've read. The documentation of TerminateProcess does not include any warning, except for the recommendation to only use it extreme circumstances, and that the global state maintained by DLLs may be compromised. Please correct me if I'm wrong, but on NT+, there isn't any global state maintained by DLLs that could get corrupted. I interpret the warning as suggesting that "normal" shutdown procedures should be used if possible. > It's easy to find long articles about the dangers on the net. Here's one I > don't think has been posted before: > > http://tinyurl.com/35o6 It mentions a number of methods to find the window, then explains that sending WM_CLOSE may fail, to finally explain that TerminateProcess should always work, and that you may lose data by using it. This is exactly the same as on Unix: If you kill a process that was just saving a file, the file may get corrupted. If there were unsaved data, they are lost. This is no reason not to use TerminateProcess. > It's certainly possible to crash Win9x by killing processes, and > easy to hang the killer process (indeed, I have four shareware > "process killers" on my home box, as no single one of them is able > to kill everything -- sometimes I have a hung process, and three > hung process killers trying to nuke it! That sounds like a bug in the killers. TerminateProcess returns immediately, according to the documentation. Now, the process may not terminate if it is blocked in the kernel (the same issue exists on Unix, leading to zombie processes). If the killer then invokes WaitForProcessClose, it is not surprising if it hangs. Your observations suggest "Don't use TerminateProcess on Win9x". I would extend this warning to "Don't use Win9x" :-) > because TerminateProcess doesn't notify attached DLLs of process > termination -- it's not solely the killed process's state that can get > hosed. Can you explain what the "global state" of a DLL is? It may have global state on Win9x, and be "attached" to a process - but I understand there is nothing "global" on NT+; the code gets mapped into the process (which gets cleaned up when the process is terminated), and there are no shared data. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4