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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 16 Sep 2012 13:15:52 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: hanche@math.ntnu.no, 12447@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>  >> Date: Sat, 15 Sep 2012 16:23:53 +0200 (CEST)
>  >> Cc: jan.h.d@swipnet.se, 12447@debbugs.gnu.org
>  >> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
>  >>
>  >> For example: Is it okay to set a timer in a timer callback?
>  >
>  > I don't see why not.  Setting up a timer just creates a Lisp object
>  > and adds it to the list of timers.  The timer will be run the next
>  > time the low-level mechanism, which is part of the Emacs exec loop,
>  > determines that it's ripe.
> 
> In js2-mode's case, the problem is that 'run-with-idle-timer' makes the
> created timer run now, not the "next time".  Here's an example:
> 
>    (defvar counter 0)
> 
>    (defun foo ()
>      (message (format  "foo %s" counter))
>      (incf counter)
>      (run-with-idle-timer 1 nil #'foo))
> 
>    (foo)

The code above does not run the timer, it just schedules it to run
after at least 1 sec of idleness time.

> I'd expect that either timer would fire once every second (as long as
> I'm not touching my keyboard), or at least stop firing when I do touch
> my keyboard (seeing as otherwise Emacs is idle), but instead I just see
> the timer firing many times a second, the counter runs in the message
> area, and Emacs doesn't respond to any commands.

Then there's a bug, because an idle timer should only fire when
there's no other input.  If there's keyboard input, Emacs should
process it first.

I don't think the bug is related to the fact that the timer handler
re-schedules itself.  That is something many timers do.  There's
something else at work here, and that something is most probably on
the C level.