bug#12447: 24.1.50; Stuck in garbage collection on OS X

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 16:07:07 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: hanche@math.ntnu.no, 12447@debbugs.gnu.org
> 
> >> Like I wrote in 12326, AFAICT, the problem is that timer_check_2 doesn't
> >> at any point check that Emacs is still idle. When run-with-idle-timer
> >> calls (timer-activate-when-idle timer t), the new timer is added to the
> >> list, timer_check_2 reaches is and runs it immediately because
> >> 'timer_idleness_start_time' still has the same value.
> >
> > If that is the problem, then perhaps having timer_check_2 work on a
> > copy of the list would solve the problem.  Did you try that?
> 
> I'm no C programmer, so I didn't try to fix it in C code. How would I 
> make a copy of a list there?

Using the Fcopy_sequence function, I'd think.  Use it at the beginning
of the function to set the value of 'idle_timers', instead of this
line:

    idle_timers = Vtimer_idle_list;

> But no, it probably won't: the "guilty" commit made timer_check_2 
> actually return 0 after a timer fires (keeping true to the comment above 
> it), so a local copy would serve no purpose.

timer_check_2 indeed returns, but then timer_check will call it again,
because it continues calling timer_check_2 in a loop, until there's no
ripe timer.

> Assuming it would've worked, though, wouldn't it make the second 
> argument to 'timer-activate-when-idle' useless?

It isn't useless, it just means a slight delay in the "now" part of
its doc string.