bug#30182: Update

[Eli Zaretskii]

> Date: Wed, 24 Jan 2018 09:39:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: m.sujith@gmail.com, 30182@debbugs.gnu.org
> 
>  >> We don't know whether `timer-list' had actually 5 elements when
>  >> running the above code.
>  >
>  > If it didn't, then the 5th element could have only been added by
>  > another thread.
> 
> Why another thread?

How else can a data structure change while the main thread is running
code that doesn't modify the data structure?

> Fmake_list does
> 
>    for (EMACS_INT size = XFASTINT (length); 0 < size; size--)
>      {
>        val = Fcons (init, val);
>        rarely_quit (size);
>      }
> 
> so IIUC rarely_quit is eventually called with size zero.  Now we have
> 
> rarely_quit (unsigned short int count)
> {
>    if (! count)
>      maybe_quit ();
> 
> which, if count is zero, calls maybe_quit which according to
> 
>    if (!NILP (Vquit_flag) && NILP (Vinhibit_quit))
>      process_quit_flag ();
>    else if (pending_signals)
>      process_pending_signals ();
> 
> may call process_pending_signals which does
> 
>    do_pending_atimers ();
> 
> which may eventually do a schedule_atimer.
> 
> So IMHO the problem is not that rarely_quit "just throws to top-level"
> but might add a timer on the fly while the timer list is copied.

atimers and timers are two very different creatures, and I don't think
I see how atimers could be relevant to our issue.  If you do, please
tell what I'm missing in this picture.