On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter Freyther wrote:
On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote:
Good Evening,
Hi again, I don't know how you debug startUp issues. I just added an OrderedCollection into the systemdictionary and use it as a log.. time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each | FileStream stderr nextPutAll: each printString; cr].1" ... old events from saving the image... {#handleTimerEvent->7147} {#handleTimerEvent->7167} {#resumptionTime->7187} {#handleTimerEvent->7167} {#handleTimerEvent->7187} {#start->true} {#start->393102159} {#start->393102159} {#resumptionTime->3279} {#handleTimerEvent->279} {#adjustResum->-393098880} {#restoreWithActiveDelay->266} {#adjustResum->-393098601} 1 real 0m0.294s user 0m0.244s sys 0m0.048s So what happens is Delay class>>#startU is called. and ActiveDelayStartTime is being set to 393102159. Then the delay is being created and resumptionTime is set to 3279. At the first time handleTimerEvent runs the milliSecondClock jumped backwards from 393102159 to 3279 which leads to an adjustment of the time. a.) Why does the time jump backwards like this during the resumption of the image? "3279" is not the old time nor the new starting time. b.) So even if that is a "wrap" around. Why does it go wrong? Are there unit tests for the clock wraps around? Maybe it is the same reason delays just don't work after image resumption? The "first" issue appears that when start is being executed that the clock is still wrong. At the same the clock is being considered wrapped the resumption time was actually already "correct' (3279 instead of 393102159+3279). Does this ring a bell? holger