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.
The >>bindWith: or >>% is not available in Pharo and other dialects.
From a licensing point of view it is easier to introduce the Pharo
equivalent to GST than to use the GST code in Pharo. Add a simple testcase
for some parts of the API. Pharo doesn't appear to use the % and ?
syntax at all.
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.
Avoid the dispatcher process from being terminated. Dispatch the
block in a new context. This is easier than detecting the termination
and then respawn it.
Remove the PackageLoader fileInPackage statement as it is conflicting
with the export as there is no PackageLoader in Pharo. Add a Makefile
to help with invoking the export and create a compat_for_pharo.st for
the methods not provided by Pharo. The testcase is working now.
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