It is possible that the "loop" has determined there are no pending
timers but then the insertion application is executing and is
inserting a timer. Once the loop is executing again it will sleep
as there was no timer and we will miss the wake-up until there is
another timer.
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.
Holger Hans Peter Freyther