GNU bug report logs - #12326
24.2.50; js2-mode freezes on current trunk

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12326 <at> debbugs.gnu.org
Subject: bug#12326: 24.2.50; js2-mode freezes on current trunk
Date: Sun, 2 Sep 2012 18:06:30 +0200

Hello.

2 sep 2012 kl. 15:03 skrev Dmitry Gutov <dgutov <at> yandex.ru>:

> Hi Jan,
> 
> On 02.09.2012 12:35, Jan Djärv wrote:
>> 1 sep 2012 kl. 23:57 skrev Dmitry Gutov <dgutov <at> yandex.ru>:
>> 
>>> js2-mode freezes during editing in some buffers.
>>> 
>>> This has been a long-standing complaint on Mac OS X port, but now it
>>> affect Linux and Windows users too, see
>>> https://github.com/mooz/js2-mode/issues/49
>>> 
>>> Bisecting the Bazaar history (on a Windows machine) points to the
>>> month-old commit no 109470, which adds one line in `timer_check_2'.
>>> 
>> 
>> The reason for that line is to make timer_check return the time to the next timeout, not the time to some random timer.
> 
> How was it random? AFAICT, your line just breaks out of the "while" loop when a ripe timer is found, and so `timer_check_2' returns 0 time, and its caller (timer_check) calls it again.
> And before that the while loop in `timer_check_2' just ran until it reached the end of timers lists, or found a non-ripe timer.
> 
> I think the main difference is, previously, `timer_check_2' was called only once, so `now' and `idleness_now' were calculated at that time, and all timers were checked for ripeness against those values.
> 
> Now `now' and `idleness_now' are recalculated after each time a ripe timer fires, which is arguably more correct (some time has passed, after all), but doesn't leave the room for the event loop to detect new keypresses and update `timer_idleness_start_time'.

That is not the problem.
Previously timer_check_2 found a timer to run, ran that, and continued to search in the list.
If the timer callback added a timer, it may happen that that timer is inserted in the front of the list, and not checked by timer_check_2.

Now timer_check_2 finds a timer, runs that, and then returns so timer_check can call timer_check_2 again.  This makes timer_check_2 start over, checking from the beginning of the list.

> 
>> When a dialog i shown, the time to the next time is checked with timer_check and when that time is reached, the timer is run.  If timer_check returns an out of order time, timers are not run when they should be.
> 
> Didn't they they just run a little late, due to the time values, against which the difference was calculated, being slightly outdated?

The case I had was one repeating 20 second timer, and one repeating 2 second timer.
The 2 second timer would be run once, then timer_check_2 would return the difference to the 20 second timer, thus skipping some 10 invokations of the 2 second timer.

> 
>> I'm surprised that js2 functions with undefined behaviour and not with defined behaviour.
> 
> Looks like the previous behavior was more conservative.

And wrong.

> 
> I think js2-mode is only unusual in that it may schedule a new timer from within a timer callback function.

It may be that some timing issues in the handling of the timer lists still remain.

	Jan D.

Previous Next

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