From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Revise etc/DEBUG documentation Date: Tue, 06 Sep 2016 18:16:58 +0300 Message-ID: <83h99tawid.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473175699 26881 195.159.176.226 (6 Sep 2016 15:28:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 15:28:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alain Schneble Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 06 17:28:13 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 1bhIIB-0005yT-Vd for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 17:28:08 +0200 Original-Received: from localhost ([::1]:34367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhII9-0007aA-Nd for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 11:28:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhI7f-0007bL-SS for emacs-devel@gnu.org; Tue, 06 Sep 2016 11:17:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhI7Z-0001Ac-QW for emacs-devel@gnu.org; Tue, 06 Sep 2016 11:17:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhI7Z-00019y-N1; Tue, 06 Sep 2016 11:17:09 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4129 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bhI7X-0004zs-Qi; Tue, 06 Sep 2016 11:17:08 -0400 In-reply-to: <86a8fls5pb.fsf@realize.ch> (message from Alain Schneble on Tue, 6 Sep 2016 12:06:24 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:207209 Archived-At: > From: Alain Schneble > CC: > Date: Tue, 6 Sep 2016 12:06:24 +0200 > > Eli Zaretskii writes: > > > Are you sure the delay is because of Emacs being parked in pselect? > > In my testing, Emacs shuts down after C-c as soon as it gets focus. > > Yes, I'm sure. At least this is what I'm observing here (with DebPrint > calls). And yes, as soon as the frame gets focus or receives any other > MS Windows message such as WM_MOUSEMOVE (or any subprocess output), it > will terminate. But if not, it blocks until the timeout expires. 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. 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. IOW, Emacs behaves here as expected, on Windows and elsewhere. > 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.