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

From: Dmitry Gutov <[email-masked]>
Date: Sun, 02 Sep 2012 21:27:18 +0400

On 02.09.2012 20:06, Jan Djärv wrote:
> 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.

I see. That's probably the reason why it worked.

> 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.

Indeed. I wonder if scheduling an idle timer from within its callback 
with `run-with-idle-timer' is supposed to work at all.