Thanks for the feedback!

Taking multiple independent snapshots is not something I intended to leave
this way.This is what I was referring to in the "performace" part of the
issues.

Back to the main issue - I wasn't aware that pid's get reused so rapidly on
Windows.

As for the implementation - your idea sounds great but I have no idea how to
put it together.

I am able to come up with some other stuff that use snapshots and do not
kill
unrelated processes. However, they skip any processes that are spawned after
the sys_kill subroutine is called.

Now I am starting to think in another direction. Would something like:
  system("taskkill /PID XXXX /T")
... be an acceptable solution?

On Thu, Dec 19, 2013 at 7:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > 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.
>