Subject: bug#12326: 24.2.50; js2-mode freezes on current trunk

From: Jan Djärv <[email-masked]>
Date: Sun, 2 Sep 2012 18:06:30 +0200

Hello.

2 sep 2012 kl. 15:03 skrev Dmitry Gutov <[email-masked]>:

> Hi Jan,
> 
> On 02.09.2012 12:35, Jan Djärv wrote:
>> 1 sep 2012 kl. 23:57 skrev Dmitry Gutov <[email-masked]>:
>> 
>>> 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.