bug#15983: 24.3; Emacs Not Killing Child Process

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Dec 2013 18:22:06 +0200
> From: Joan Karadimov <joan.karadimov@gmail.com>
> Cc: 15983@debbugs.gnu.org, Simon Morgan <sjm@sjm.io>, 
> 	Bozhidar Batsov <bozhidar.batsov@gmail.com>
> 
> > Unfortunately, taskkill is not available widely enough.  E.g., on my
> > XP Home edition, it is not available, and I believe it is not there on
> > systems older than XP, which we still support.
> 
> I am aware that 'taskkill' is not present on windowses (is that a word?)
> older than XP. This makes it no worse than 'CreateToolhelp32Snapshot'.

No, the toolhelp functions are available on Windows 2000 and even on
Windows 98.  They are unavailable only on NT 4.0.

> > This might be "good enough" -- we err on the safe side, and only leave
> > some subprocesses not killed in rare situations.  Does this strategy
> > solve the problem which started this bug report?

You didn't answer that question, but I assume the answer is YES.

>  If so, please tell
> > the main ideas of how you intend to avoid killing unrelated processes.
> 
> Here is some pseudo-code for it...
> 
> # This returns [a subset] of the edges in the process tree
> def get-process-tree:
>   1. let process-snapshot be the current process snapshot
>   2. let process-tree be an empty list
>   3. for parent-pid, child-pid in process-snapshot:
>        if process-start-time(child-pid) < process-start-time(parent-pid):
>          add(process-tree, (parent-pid . child-pid))

I think it would be better to also require that process-start-time is
before the time kill-process-tree is called.  This might miss some
children, if they happen to be spawned right after the call, but it is
safer.

Also, didn't you mean ">" in the above inequality?  A child process
cannot be born before its parent, right?  Or am I missing something?

> 
> def kill-process-tree(root-process):
>   1. open a process handle to the root-process (I am guessing that Emacs
> already
>      keeps a handle to all process it spawned so this step might be
> unnecessary)

Yes, Emacs already keeps a handle on each of its immediate child
processes.  That's how we know that those children exit.

> Other potential issue is the non-atomicity of step (4.) and the
> possibility of grabbing a handle to a process that wasn't in
> initial-process-tree. I claim that this is not an issue, because
> those will not end up in revised-kill-list.
> 
> Both, of course, I cannot prove formally. But so far I have been
> unable to find counterexamples.

The only thing that we should worry about is not to accidentally kill
unrelated processes.  Everything else is no worse than what we have
now.