GNU bug report logs - #17392
24.3.90; cursor blinks faster and faster

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17392 <at> debbugs.gnu.org
Subject: bug#17392: 24.3.90; cursor blinks faster and faster
Date: Sun, 11 May 2014 13:09:30 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So I'm asking whether you are sure what you see is a real problem, and
> not some artifact of how you look for a problem.

No, I'm not sure.  And I didn't want to convince you, on the contrary, I
need help to find it out.  My knowledge of the C code is limited.


Here is what I do know for sure:  Evaluating

--8<---------------cut here---------------start------------->8---
(progn
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil
                         (lambda () (sit-for 2.)
			   (message "%s" (length timer-idle-list)))))
  (defadvice handle-switch-frame (after provoke activate)
    (provoke)))
--8<---------------cut here---------------end--------------->8---

and switching frames with M-TAB leads to a situation where multiple
timers running blink-cursor-start are present in timer-idle-list.  These
timers are all `equal', but not `eq' - they are different objects.

I advised all functions named timer-... to count the number of
_different_ timers running `blink-cursor-start' (those in
timer-idle-list, plus the one maybe bound to blink-cursor-idle-timer)
before and after the call to the function.  I can post the code if you
want.

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.

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.

Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.