[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17392: 24.3.90; cursor blinks faster and faster
From: |
Eli Zaretskii |
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@web.de>
> Cc: 17392@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?
- bug#17392: 24.3.90; cursor blinks faster and faster, (continued)
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/06
- bug#17392: 24.3.90; cursor blinks faster and faster, Stefan Monnier, 2014/05/07
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/08
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/08
- bug#17392: 24.3.90; cursor blinks faster and faster, Lennart Borgman, 2014/05/08
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/08
- bug#17392: 24.3.90; cursor blinks faster and faster, Lennart Borgman, 2014/05/08
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/10
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/10
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/10
- bug#17392: 24.3.90; cursor blinks faster and faster,
Eli Zaretskii <=
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/10
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/11
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/11
- bug#17392: 24.3.90; cursor blinks faster and faster, Michael Heerdegen, 2014/05/13
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/13
- bug#17392: 24.3.90; cursor blinks faster and faster, Lennart Borgman, 2014/05/13
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/13
- bug#17392: 24.3.90; cursor blinks faster and faster, Lennart Borgman, 2014/05/13
- bug#17392: 24.3.90; cursor blinks faster and faster, Eli Zaretskii, 2014/05/13
- bug#17392: 24.3.90; cursor blinks faster and faster, Lennart Borgman, 2014/05/13