[Python-Dev] RE: how to kill process on Windows started with os.spawn?

[Martin v. Löwis]

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