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

[Jan Djärv]

Hello.

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

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