Holger Hans Peter Freyther wrote:
On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote:
Good Evening,
I have a report that it doesn't work on a linux desktop either. So at least there is one case where it does not work in a non-virtualized environment. Maybe interesting:
root@2d-misc:/opt/mock-server# time pharo-vm-nox ./Pharo.image eval "(Delay forSeconds: 5) wait. (Delay forSeconds: 10) wait" a Delay(10000 msecs)
yes the first delay seems to fail. I have some holes in my analysis but so far I see:
Process A (Delay forSeconds: 5) wait Delay class >> scheduleDelay aDelay resumptionTime: 5622
Process B Delay class >> handleTimerEvent is being executed "Check for clock wrap-around." nowTick := Time millisecondClockValue. nowTick < ActiveDelayStartTime ifTrue: [ "clock wrapped" ... self restoreResumptionTimes
Delay class >> restoreResumptionTimes mydelay adjustResumptiomTimeOldBase: mydelay's resumptionTime is now negative. but the time base hasn't been changed as the Delay was started _after_ the image has been resumed (or at least while it is being resumed).
... nowTick >= ActiveDelay resumptionTime ifTrue: [ ActiveDelay signalWaitingProcess.
What I notice is that:
restoreResumptionTimes "Private! Restore the resumption times of all scheduled Delays after a snapshot or clock roll-over. This method should be called only while the AccessProtect semaphore is held."
But handleTimerEvent doesn't seem to use AccessProtect. The comment and implementation appear to be not consistent.
holger
#handleTimerEvent runs in the highest priority process at TimingPriority=80. The AccessProtect mutex is about controlling how multiple lower priority processes poke instances of Delay into the ScheduledDelay and FinishedDelay variables for #handleTimerEvent to process (being invoked by signaling TimingSempahore from within the AccessProtect). However restoreResumptionTimes is also called from #startUp by low priority processes and that is probably when AccessProtect is required. However2, I am working on an alternative implementation to use Semaphores rather than the AccessProtect mutex, which should bypass your concern. It should be ready for review early next week. cheers -ben