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: Revise etc/DEBUG documentation Date: Mon, 5 Sep 2016 21:19:58 +0200 Message-ID: <86inuarw69.fsf@realize.ch> References: <864m5xtgtf.fsf@realize.ch> <838tv9dxu1.fsf@gnu.org> <86zinpruq0.fsf@realize.ch> <8360qddpc7.fsf@gnu.org> <86vaycslct.fsf@realize.ch> <83mvjnd8uw.fsf@gnu.org> <86mvjnske9.fsf@realize.ch> <831t0ycnhd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1473103410 17378 195.159.176.226 (5 Sep 2016 19:23:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Sep 2016 19:23:30 +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 Mon Sep 05 21:23:27 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 1bgzUI-0003QL-KC for ged-emacs-devel@m.gmane.org; Mon, 05 Sep 2016 21:23:22 +0200 Original-Received: from localhost ([::1]:56601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzUG-00014n-4D for ged-emacs-devel@m.gmane.org; Mon, 05 Sep 2016 15:23:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzRt-0008N8-PP for emacs-devel@gnu.org; Mon, 05 Sep 2016 15:20:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgzRs-0004w6-Pa for emacs-devel@gnu.org; Mon, 05 Sep 2016 15:20:53 -0400 Original-Received: from clientmail.realize.ch ([46.140.89.53]:3557) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1bgzRn-0004uW-FW; Mon, 05 Sep 2016 15:20:47 -0400 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Mon, 5 Sep 2016 21:20:34 +0200 Original-Received: from MYNGB (192.168.66.64) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Mon, 5 Sep 2016 21:19:55 +0200 In-Reply-To: <831t0ycnhd.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Sep 2016 19:36:46 +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:207204 Archived-At: Eli Zaretskii writes: >> > It is actually more complicated than that, because the same Emacs >> > session could have some GUI frames and some text-mode frames (though >> > not on MS-Windows). That's why saying "Emacs executes as GUI" is >> > problematic at best. >> >> I didn't even know that this is possible. Thanks for pointing it out. > > See keyboard.c:handle_interrupt_signal for how that complication is > handled. Thanks. Now I think I finally understand what the comment about multiple display types and SIGINT in init_keyboard.c:10886 (cfaf18a) really means :) > Btw, I found that the MS-Windows build wasn't catching SIGINT in GUI > sessions like the Posix platforms do, and I will fix that in a few > moments. That was exactly one of the things that confused me and what I tried to document in my initial patch by saying "On MS-Windows, [...]. GDB treats them as a SIGINT, but Emacs won't terminate as it ignores these events." ^^^^^^^^^^^^^^^^^^^^ With this fix, this confusion is gone. Thanks. Just one small thing: After sending a SIGINT, it might take some time until Emacs actually terminates as it might be blocked in pselect emulation (sys_select) in the call to MsgWaitForMultipleObjects. Just wonder if there is an easy way to send a message or such to get out of the blocking call without having to wait for a timeout or another event to happen. I guess that does not happen on POSIX as the corresponding syscall will be interrupted anyway, right?