bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 17392@debbugs.gnu.org
> Date: Sun, 11 May 2014 13:09:30 +0200
> 
> This count should always be <= 1, right?  With the advices, I was
> interested in the first time when the count is > 1, i.e., when the state
> switched from sane to pathological.
> 
> And I found that the count was > 1 for the first time after
> `timer-event-handler' had been called (from C).  Before that call the
> count had still been 1.  And I know why the count increased: namely because
> the timer object that timer-event-handler was called with was not
> present (referable) from the Lisp level at that point of time.  But
> another (equal, but not eq) timer was present in timer-idle-list.
> 
> Due to lack of C knowledge, I can't interpret that result.  But it shows
> that the C level is definitely involved, and the bug is not in timer.el,
> at least, not only.

The C level is definitely involved, because it is the one which
actually runs the timers.  But is the C level involved in the bug?
I'm not sure, as I saw no evidence to that effect yet.

> Summa summarum: no, I don't know if this `timer-event-handler' call from
> C is unkosher, but it is the mechanism that leads to successive
> additions of blink-cursor-start timers to timer-idle-list.

The blink-cursor-start timers are added by blink-cursor-check, so
perhaps the problem is there?  E.g., it doesn't check timer-idle-list,
it only checks that blink-cursor-idle-timer is nil.

The function blink-cursor-check is called from two places:
post-command-hook and handle-focus-in (via focus-in-hook).  Could it
be that in your scenario two timers are started due to this?