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: Tue, 6 Sep 2016 18:14:42 +0200 Message-ID: <8660q9ronh.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> <86inuarw69.fsf@realize.ch> <83r38xbvk8.fsf@gnu.org> <86a8fls5pb.fsf@realize.ch> <83h99tawid.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1473179191 18635 195.159.176.226 (6 Sep 2016 16:26:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 16:26:31 +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 Tue Sep 06 18:26:26 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 1bhJCR-0003Bj-BP for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 18:26:15 +0200 Original-Received: from localhost ([::1]:34918 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhJCP-0001qT-B7 for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 12:26:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhJ1t-0001vA-LX for emacs-devel@gnu.org; Tue, 06 Sep 2016 12:15:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhJ1p-0007pG-FT for emacs-devel@gnu.org; Tue, 06 Sep 2016 12:15:21 -0400 Original-Received: from clientmail.realize.ch ([46.140.89.53]:4614) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1bhJ1k-0007lv-Hi; Tue, 06 Sep 2016 12:15:12 -0400 Original-Received: from rintintin.hq.realize.ch.lan.rit ([192.168.0.105]) by clientmail.realize.ch ; Tue, 6 Sep 2016 18:15:00 +0200 Original-Received: from MYNGB (192.168.250.224) by rintintin.hq.realize.ch.lan.rit (192.168.0.105) with Microsoft SMTP Server (TLS) id 15.0.516.32; Tue, 6 Sep 2016 18:14:34 +0200 In-Reply-To: <83h99tawid.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 06 Sep 2016 18:16:58 +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:207211 Archived-At: Eli Zaretskii writes: > But in that case, this is expected behavior: the SIGINT handler just > sets a flag and returns; the flag is then processed whenever the Emacs > event loop cranks one more cycle. This is not specific to MS-Windows. > In an idle "emacs -Q", you might indeed see a difference between > Windows and Posix systems, because on the latter pselect will be > interrupted by SIGINT. Exactly. This was the unexpected behavior I was referring to. > But that is not a very interesting use case > for shutting down Emacs with SIGINT. A real-life Emacs session has > several timers running, which typically make pselect waits shorter, > and if Emacs is in the middle of some prolonged computation, you will > see a delay on Posix platforms as well. Indeed. > IOW, Emacs behaves here as expected, on Windows and elsewhere. I looked at it as a white box, and this was not what /I/ expected. From a users point of view and when looking at real cases, it doesn't really matter, I agree. >> This potential delay is a minor detail. But couldn't we overcome it by >> pulsing the interrupt_handle event, e.g. by a call to signal_quit in >> keyboard.c (handle_interrupt_signal), just after having set the >> Vquit_flag? Of course, that would be for MS Windows only. > > I see no reason, see above. In any case, I'd advise against doing > anything non-trivial in the SIGINT handler, on Windows in particular, > because Windows runs such handlers in a separate thread, so it's > unsafe to do there anything non-trivial -- we could easily crash, > because we are on the wrong stack. Ok, sure. (Even though I don't think that PulseEvent would do any hurt here...) Thanks for your explanations.