[squeak-dev] Delays getting mangled across save

Casey Ransberger casey.obrien.r at gmail.com
Thu Aug 8 07:23:10 UTC 2013


I stopped reading the Pharo list because there was *so* much traffic that I
couldn't see my own email through it. And most of the traffic wasn't
terribly interesting to me. Is there code we can (maybe modify and) use?

I don't think there's anything wrong with forwarding an exigent discussion
from that pharo list here, we just need an "exigency filter" who reads the
Pharo list *nudge.*


On Wed, Aug 7, 2013 at 8:36 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> Everyone here is aware of the enormous amount of traffic on the Pharo
> list about getting these kinds of Delay problems sorted out, right?
>
> frank
>
> On 7 August 2013 16:14, Bert Freudenberg <bert at freudenbergs.de> wrote:
> > Yes, making Delays work accurately wrt wall-clock time would be more work
> > now that I think about it. This seems to be better handled in a
> higher-level
> > object.
> >
> > - Bert -
> >
> > On 2013-08-07, at 16:16, Bob Arning <arning315 at comcast.net> wrote:
> >
> > 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> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130808/d4664223/attachment.htm


More information about the Squeak-dev mailing list