From TRAC Ticket #7045 (karl ramberg)

(karl) The TimesRepeat tile does a tight inner loop that it is easy to make recourse infinitely or seemingly blocks the etoy environment while executing. Alt + . is often the only way to break out of this loop because the world is not updating or pick up mouse clicks.


(scott) The same issue arises quite independently of the times/repeat tile when one considers that any textual script can have an infinite loop in it. So the issue really is: what protections can we provide for detecting, or at least recovering from, infinite loops in user scripts?
  

(karl) Ugh, this is not easy. Could scripts run in a separated lower priority process and add feedback with WorldState>>addDeferredUIMessage: ?


(bert) One could terminate a script if it takes longer than x seconds to execute:

    sema := Semaphore new.
    script := [result := self doScript. watchdog terminate. sema signal] newProcess.
    watchdog := [(Delay forSeconds: 1) wait. script terminate. sema signal] forkAt: Processor activePriority+1.
    script resume.
    sema wait.
    ^result

We could possibly ask the user if the script should be terminated or be allowed to continue for x more seconds.

In the case of the repeat tile, it would be preferable to terminate the loop only when it finished a cycle (rather than by termianting it) - it could have a flag that is tested in each cycle which is set after n seconds from a watchdog like the above.


(karl) We could possibly ask the user if the script should be terminated or be allowed to continue for x more seconds. In the case of the repeat tile, it would be preferable to terminate the loop only when it finished a cycle (rather than by termianting it) - it could have a flag that is tested in each cycle which is set after n seconds from a watchdog like the above.

Yes, because the current situation is not nice when a times repeat script is accidentally set to ticking