From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joan Karadimov Newsgroups: gmane.emacs.bugs Subject: bug#15983: 24.3; Emacs Not Killing Child Process Date: Sat, 21 Dec 2013 18:22:06 +0200 Message-ID: References: <83ob4cbvot.fsf@gnu.org> <83txe2aad0.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d04428e3ab606eb04ee0dcbc9 X-Trace: ger.gmane.org 1387642991 18430 80.91.229.3 (21 Dec 2013 16:23:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 16:23:11 +0000 (UTC) Cc: Simon Morgan , Bozhidar Batsov , 15983@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 21 17:23:17 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VuPKe-0006ig-Lk for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Dec 2013 17:23:16 +0100 Original-Received: from localhost ([::1]:54734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuPKe-00018N-2l for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Dec 2013 11:23:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuPKV-00018H-VP for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 11:23:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuPKQ-0000ta-NL for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 11:23:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuPKQ-0000tI-JA for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 11:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VuPKQ-0003Z8-52 for bug-gnu-emacs@gnu.org; Sat, 21 Dec 2013 11:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Joan Karadimov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Dec 2013 16:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15983 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: Original-Received: via spool by 15983-submit@debbugs.gnu.org id=B15983.138764293113587 (code B ref 15983); Sat, 21 Dec 2013 16:23:02 +0000 Original-Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 16:22:11 +0000 Original-Received: from localhost ([127.0.0.1]:33403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuPJa-0003X3-1Q for submit@debbugs.gnu.org; Sat, 21 Dec 2013 11:22:10 -0500 Original-Received: from mail-wg0-f48.google.com ([74.125.82.48]:51176) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuPJX-0003Wp-F0 for 15983@debbugs.gnu.org; Sat, 21 Dec 2013 11:22:08 -0500 Original-Received: by mail-wg0-f48.google.com with SMTP id z12so3544831wgg.3 for <15983@debbugs.gnu.org>; Sat, 21 Dec 2013 08:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k8rLqnmEQMxaowiaL/eFmfasR7o4JAGTDfgx0NOeqN4=; b=g/aYl2YOa2dsJCBdiKTIRAIm3Fi7bcthK5SE7NY8L+K8SRonf/4gBqxekDH/tqln2w b+GjtqwGDgqXe+jl4+2cJpFkLeWd59EmTIvaqquH/8QItX6SlQkQVHCC7IsNZ9pFdKKA OLGqr9oVQqYVsRhw+ybLXNwuHETBYry+EPjdSI9OjXUjfC3ntHurFTGG+RYjrimAnZFK CJo53VLHrodC5zkhIkeWqASjcUrJTMj81GkVwUWvDcPTLohMeKtdgG43maqUuLWWW390 oLQ8RFCR006kuf10b1+Id4dT54vv2vqvVEN3YLzUgT2cXK+SMlIobd3dofOjcixpKdr2 hEjQ== X-Received: by 10.180.103.193 with SMTP id fy1mr12683854wib.10.1387642926530; Sat, 21 Dec 2013 08:22:06 -0800 (PST) Original-Received: by 10.216.127.68 with HTTP; Sat, 21 Dec 2013 08:22:06 -0800 (PST) In-Reply-To: <83txe2aad0.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82334 Archived-At: --f46d04428e3ab606eb04ee0dcbc9 Content-Type: text/plain; charset=ISO-8859-1 > 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'. But I din't know of its absence from home editions. My first thought was to seek inspiration in the Wine project: (https://github.com/mirrors/wine/blob/master/programs/taskkill/taskkill.c) ... only to find: WINE_FIXME("/T not supported\n"); ... so this seems like a dead end. > 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? 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)) 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) 2. let initial-process-tree be the return value of get-process-tree 3. let inital-kill-list be the edges from initial-process-tree that are reachable from the root-process 4. open process handles to every child-pid from inital-kill-list 5. let revised-process-tree be the return value of get-process-tree 6. let revised-kill-list be the intersection of inital-kill-list and revised-process-tree 7. kill and close handles to child processes in final-kill-list 8. close any remaining handles from step (4.) There are a few non-obvious things here that need a skeptical reading. The most arcane is that step (6.) in kill-process-tree really returns what we need to kill. 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. --f46d04428e3ab606eb04ee0dcbc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Unfortunately, taskkill is not available widely = enough. =A0E.g., on my
> XP Home edition, it is not availa= ble, 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 w= orse than 'CreateToolhelp32Snapshot'. But I din't
know of its absence from home editions. My first thought was to seek inspir= ation
in the Wine project:
... only to find:
=A0 WINE_FIXME("/T not supported\n&qu= ot;);
... so this seems like a dead end.

> This might be "good enough" -- we err on the safe side, and= only leave
> some subprocesses not killed in rare situations. =A0Does this strategy=
> solve the problem which started this bug report? =A0If so, please = tell
> the main ideas of how you intend to avoid killing unrelated pr= ocesses.

Here is some pseudo-code for it...

=
# This returns [a subset] of the edges in the process tree
=
def get-process-tree:
=A0 1. let process-snapshot be the cur= rent process snapshot
=A0 2. let process-tree be an empty list
=A0 3. for parent-p= id, child-pid in process-snapshot:
=A0 =A0 =A0 =A0if process-star= t-time(child-pid) < process-start-time(parent-pid):
=A0 =A0 = =A0 =A0 =A0add(process-tree, (parent-pid . child-pid))

def kill-process-tree(root-process):
=A0 1. o= pen a process handle to the root-process (I am guessing that Emacs already<= /div>
=A0 =A0 =A0keeps a handle to all process it spawned so this step = might be unnecessary)
=A0 2. let initial-process-tree be the return value of get-process-tre= e
=A0 3. let inital-kill-list be the edges from initial-process-t= ree that are
=A0 =A0 =A0reachable from the root-process
=A0 4. open process handles to every child-pid from inital-kill-list
=A0 5. let revised-process-tree be the return value of get-process-tre= e
=A0 6. let revised-kill-list be the intersection of inital-kill= -list and
=A0 =A0 =A0revised-process-tree
=A0 7. kill a= nd close handles to child processes in final-kill-list
=A0 8. close any remaining handles from step (4.)

=
There are a few non-obvious things here that need a skeptical reading.=

The most arcane is that step (6.) in kill-process= -tree really returns what we
need to kill.

Other potential issue is t= he non-atomicity of step (4.) and the possibility of
grabbing a h= andle 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-li= st.

Both, of course, I cannot prove formally. But = so far I have been unable to find
counterexamples.

--f46d04428e3ab606eb04ee0dcbc9--