Avoid a potential race condition. Assign the loop variable before
starting the process. Otherwise the effect on loop could be that a
terminated process is being assigned.
Spotted while reviewing a problem Norbert experienced in Pharo
After a timer has been canceled we can forget about the block
that was supposed to be canceled. It is only a matter of time
until the timer will be discarded by the TimerScheduler.
In Pharo the Delay>>wait for one second will not expire anytime soon
in a new image. Use the depedency handling so we can terminate and
restart the loop.
Make sure that we only remove from one process, this way we can
check if the list is empty without having a lock. The list is sorted
so even if we get interrupted between the [condition] whileFalse: [res]
and someone adds an older timer, it is okay to use this timer.
When dispatching everything in the same context we avoid all kind
of issues with locking. If we use a truely multi threaded VM we could
probably use multiple dispatchers.