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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 17392 <at> debbugs.gnu.org
Subject: bug#17392: 24.3.90; cursor blinks faster and faster
Date: Sat, 10 May 2014 15:32:10 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 17392 <at> debbugs.gnu.org
> Date: Sat, 10 May 2014 13:40:26 +0200
> 
> > > So an idle blinking timer not in timer-idle-list is called from C
> > > with timer-event-handler.  At this point, there is already another
> > > blinking timer in timer-idle-list.
> >
> > So is there a blinking time in timer-idle-list, or isn't there?
> 
> There is one blinking timer in timer-idle-list.  But timer-event-handler
> is called with a different blinking timer that is not memq in
> timer-idle-list.

How can that happen?  The only place AFAIK that calls idle timers is
keyboard.c, and it takes the timers off timer-idle-list.  Since
Emacs's Lisp interpreter is single-threaded, how could the situation
you describe happen?

> It seems that the implementation detail you cited leads in our case to
> the revival of canceled timers although there haven't been activated
> from LISP?

Maybe so, but again, you'd need to describe a sequence of events that
could lead to this.  Every time timer_check is called, it starts by
copying the current value of timer-idle-list, and doesn't consider it
again until it processed that copy entirely.  The Lisp interpreter is
not called except when we call a timer function taken from the list.

So if a timer is canceled before timer_check is called, it will be
absent from the copy used by timer_check, and if it is canceled as
part of some timer's operation, it won't be there on the next
invocation of timer_check.  Right?  So how could a timer be revived if
it was canceled?  More to the point, which of the blink-cursor timers
could potentially cause this situation?

Is there a chance handle-focus-in is called asynchronously by a thread
other than the one which runs the Lisp interpreter?  I don't think so
(and if it did, it would be a very Bad Thing), but other than that,
how can you explain that a timer got off timer-idle-list while that
same timer was found in that same list by a C code which cannot be
preempted by any Lisp?

Previous Next

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