bug#21380: 25.0.50; GTK-induced segfault when scheduling timer from window-configuration-change-hook

[Stefan Monnier]

> What do you mean by "have read the variable"?  We are "reading" it one
> member at a time, as timer_check goes about its business.

The Vtimer_list variable is read once and for all at the beginning of
timer_check.  After that, this variable is unused until we finish
processing all the timers in the list.  This processing uses the list
that was contained in this variable, but it doesn't use the variable
itself.  So modifying the list during the loop can be problematic
(hence the use of copy-sequence to avoid interference), whereas
modifying the variable isn't.

>> How could it be worse to allocate cells when we activate a timer than
>> copying the whole list every time we check the timers?
> Twice worse, I'd say (assuming "a couple" really means 2).

What kind of scenario are you imagining.
My reasoning I have in mind is this:

- Every time Emacs is idle, it runs check_timers.
- We don't run timers every time Emacs is idle (because it becomes
  un-idle before it gets a chance to run those timers).
- Most commands don't activate timers (but they end by running check_timers).
- Only some timers end up calling activate-timer.

So, I get the impression that check_timers should be run (much?) more
often than activate-timer.

> But this is not the important issue right now.  Right now, I don't
> understand how your proposal will solve this and related bugs.

Neither do I.  But if replacing Fcopy_sequence by a new
copy_sequence_without_QUIT fixes the bug, then I don't see why replacing
it with a nop wouldn't fix it just as well.


        Stefan