[squeak-dev] Delays getting mangled across save

Bob Arning arning315 at comcast.net
Wed Aug 7 14:16:04 UTC 2013


I was thinking about that, but I suspect there are use cases for both 
image time and real-world time. Maybe something like

(Delay until: someRealTime) wait

would meet the need the current Delay does not.

Cheers,
Bob

On 8/7/13 9:54 AM, Bert Freudenberg wrote:
> That has to be one of the oldest bugs! It's been there forever. I just 
> committed that to trunk.
>
> There is still a problem though. Squeak's delays (with Bob's fix) are 
> based on image "running time". That is, if I have a 1 hour delay and 
> snapshot the image after 45 minutes, on the next day it will expire 15 
> minutes after starting the image.
>
> But arguably a delay should really expire by the same wall-clock time 
> as when it was scheduled, even across snapshots. This is how it was 
> handled in Smalltalk-80. Here's the ST80 code:
>
> Delay>>preSnapshot
> "convert from local millisecond clock to milliseconds since Jan. 1 1901"
> pendingDelay _ resumptionTime - Time millisecondClockValue.
> resumptionTime _ Time totalSeconds * 1000 + pendingDelay
>
> Delay>>postSnapshot
> "convert from milliseconds since Jan. 1 1901 to local millisecond clock"
> pendingDelay _ resumptionTime - (Time totalSeconds * 1000).
> pendingDelay _ pendingDelay max: 0.
> resumptionTime _ Time millisecondClockValue + pendingDelay
>
> Of course, we would have to use UTC nowadays but I still think 
> re-implementing this would be a good idea.
>
> In any case, the fix makes the Delay snapshotting behavior at least 
> predictable :)
>
> - Bert -
>
> On 2013-08-06, at 21:57, Bob Arning <arning315 at comcast.net 
> <mailto:arning315 at comcast.net>> wrote:
>
>> Well, this seems to fix it:
>>
>> 'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 6 August 
>> 2013 at 3:39:29 pm'!
>>
>> !Delay class methodsFor: 'snapshotting' stamp: 'raa 8/6/2013 15:22'!
>> 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."
>>
>>     | newBaseTime |
>>     newBaseTime := Time millisecondClockValue.
>>     SuspendedDelays do: [:d | d adjustResumptionTimeOldBase: 0 
>> newBase: newBaseTime].
>>     ActiveDelay == nil ifFalse: [
>>         ActiveDelay adjustResumptionTimeOldBase: 0 newBase: newBaseTime.
>>     ].
>>     ActiveDelayStartTime _ newBaseTime "<-----this"! !
>>
>> Cheers,
>> Bob
>>
>> On 8/6/13 3:27 PM, tim Rowledge wrote:
>>> Well the timer stuff has certainly been messed about with a lot since I last had to dig into it, but it looks like it *ought* to work ok.
>>>
>>> The only likely culprit I can spot is some issue with adjusting the resumption times after the restart, but that would require some problem with the millisecond time prim.
>>>
>>>
>>> tim
>>> --
>>> tim Rowledge;tim at rowledge.org;http://www.rowledge.org/tim
>>> Strange OpCodes: YVR: Branch to Vancouver
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130807/bb937b2c/attachment.htm


More information about the Squeak-dev mailing list