From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alain Schneble Newsgroups: gmane.emacs.devel Subject: Re: SIGTRAP in kill emulation on Windows Date: Fri, 26 Aug 2016 11:47:36 +0200 Message-ID: <86vaynhnev.fsf@realize.ch> References: <86d1kwj37g.fsf@realize.ch> <83bn0gesab.fsf@gnu.org> <868tvkiplu.fsf@realize.ch> <83wpj4c4yz.fsf@gnu.org> <86zinzhpnx.fsf@realize.ch> <83shtrdhb0.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472205009 11527 195.159.176.226 (26 Aug 2016 09:50:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Aug 2016 09:50:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 26 11:50:05 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdDm0-0002l9-QF for ged-emacs-devel@m.gmane.org; Fri, 26 Aug 2016 11:50:04 +0200 Original-Received: from localhost ([::1]:59754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdDly-0000NL-Be for ged-emacs-devel@m.gmane.org; Fri, 26 Aug 2016 05:50:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdDk9-00089H-TR for emacs-devel@gnu.org; Fri, 26 Aug 2016 05:48:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bdDk8-0003s2-Vz for emacs-devel@gnu.org; Fri, 26 Aug 2016 05:48:09 -0400 Original-Received: from clientmail.realize.ch ([46.140.89.53]:2664) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1bdDk2-0003qk-Ne; Fri, 26 Aug 2016 05:48:03 -0400 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Fri, 26 Aug 2016 11:48:00 +0200 Original-Received: from MYNGB (192.168.66.65) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Fri, 26 Aug 2016 11:47:37 +0200 In-Reply-To: <83shtrdhb0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Aug 2016 12:13:07 +0300") X-ClientProxiedBy: rintintin.hq.realize.ch.lan.rit (192.168.0.105) To rintintin.hq.realize.ch.lan.rit (192.168.0.105) X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] X-Received-From: 46.140.89.53 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206816 Archived-At: Eli Zaretskii writes: >> From: Alain Schneble >> CC: >> Date: Fri, 26 Aug 2016 10:58:58 +0200 >> >> Eli Zaretskii writes: >> >> Yes, debugbreak and the proposed implementation behave identically. > > Then I guess that's a limitation we will have to live with. It > doesn't sound like a grave one to me: after all, what exactly SIGTRAP > does when no debugger is attached is not very important, since that is > not the primary use case for that signal, AFAIU. If a Lisp program > wants to kill the process, it doesn't need to use SIGTRAP. I agree. >> Yes, and on GNU/Linux I observed that it prints a backtrace prior to >> termination. > > That depends on ulimit and suchlikes, I think: on a GNU/Linux system I > tried that, the program was simply dumped to the shell prompt without > printing anything. Ok, thanks for the hint. >> But that's kind of irrelevant here I guess. Where would be the best >> place to document this quirk (c, signal-process, info manual)? > > Actually, perhaps not even there. In NEWS might be enough, I think. Ok, I'll arrange a new patch with that added to the NEWS entry. >> FWIW, there is probably something we could do about it -- query if the >> process in question is attached to a debugger. If not, we could >> terminate it. > > That's for the application to decide, IMO. Signal delivery is too > low-level to replace one signal with another one. That's a good point. I agree with you.