Re: Revise etc/DEBUG documentation

[Alain Schneble]

Eli Zaretskii <address@hidden> 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.