bug#15983: 24.3; Emacs Not Killing Child Process

[Eli Zaretskii]

> Date: Thu, 19 Dec 2013 17:44:37 +0200
> From: Joan Karadimov <joan.karadimov@gmail.com>
> Cc: sjm@sjm.io, eliz@gnu.org, Bozhidar Batsov <bozhidar.batsov@gmail.com>
> 
> > Emacs on Windows can only monitor and kill its immediate subprocesses,
> > it cannot monitor, let alone kill, any of their descendant processes,> 
> > because it has no idea about them.  And the OS doesn't automatically> kill 
> > all the processes in the subprocess tree, and there's no way to> send a 
> > signal to them all, as on Posix platforms.  If killing the> immediate child 
> > process doesn't cause some of its children to exit or> abort, then those 
> > grandchildren will be left orphaned.
> Windows NT does have the concept of parent processes, but an API call
> wasn't exposed in win32 until XP. I wrote a small patch that uses that
> and kills all child processes (as long as pid<0). I did some sanity
> testing and it works.

Thanks, but I don't think we can use this code safely: there's a race
condition here between the time the snapshot is taken and the time the
process in the snapshot is killed.  During this time window, however
small, a process ID can be reused for a completely different process.
Killing an unrelated process is a no-no.

Moreover, AFAIU the code takes multiple independent snapshots of the
process tree, which are not guaranteed to be consistent between them
on a live system which resuses process IDs as fast as Windows does.

The only safe way on Windows to make sure a process ID is not reused
is to keep a handle open on the process.  But such a strategy would
require some kind of notification to Emacs from its subprocesses when
they launch their subprocesses.  If you (or someone else) know how to
set this up, we could indeed resolve this problem.  Otherwise, I'm
afraid we will need to live with this some more.

> - there is no OS detection - this will get ugly on Windows 9x and
> NT4/5.0

This is not a problem: we already call these functions in Emacs, and
have the necessary machinery to detect whether the API is available.
Take a look at create_toolhelp32_snapshot in w32.c, and its callers.

> - performance: 3 API calls are made for each descendant
> process. This can be reduced to a total 3 calls (regardless of the
> child process count)

I doubt that this should count as a problem, since we are talking
about extreme cases anyway.

The only real problem is the one I mention above.

Thanks for working on this.