Re: Revise etc/DEBUG documentation

[Eli Zaretskii <eliz@gnu.org>]

> From: Alain Schneble <a.s@realize.ch>
> CC: <emacs-devel@gnu.org>
> Date: Tue, 6 Sep 2016 12:06:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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.