[squeak-dev] Delays getting mangled across save

Frank Shearar frank.shearar at gmail.com
Thu Aug 8 07:49:13 UTC 2013


On 8 August 2013 05:29, David T. Lewis <lewis at mail.msen.com> wrote:
> On Wed, Aug 07, 2013 at 01:36:34PM -0400, Bob Arning wrote:
>> OTOH, don't borrow trouble.
>>
>> Cheers,
>> Bob
>
> Wise counsel indeed. The Pharo folks made an attempt to fix the problem
> without understanding it, hence the subsequent flurry of bug fixing
> activity on that list.
>
> There is a real underlying problem in that the Squeak VMs report time
> to the image in local time rather than UTC, and any attempt to handle
> durations based on wall clock time will inevitably run afoul of time zone
> and daylight savings time problems.

Well, of course, there is only one time zone, and that's one that is
Universal and Coordinated. So when I say "wall clock" I mean "wall
clock with the correct time, that is, a Time that is Universal and
Coordinated".

(I'm not so pushy about this because I live in London, for the record
(which has the wrong time at the moment, because of British Summer
Time), but because UTC is the only sane timezone, except maybe for
some rather esoteric timezones like UT.)

> The necessary primitives to report system time based on UTC have been
> present in both the standard VM and Cog for some time, but incorporating
> this into the image is a non-trivial exercise.

Right, so maybe my worries about Windows have already been addressed,
except for that small minor insignificant "integration" detail.

So what do we need to do to get correct time in a Squeak? Since it
sounds like an image side problem, it's something the entire community
can help with.

frank

> My understanding, based on some interesting archaeologic evidence that
> Eliot unearthed from ancient scrolls in his basement, is that Smalltalk
> was originally implemented with a system clock that was based on non-local
> time (correct), and that, possibly as a matter of convenience, the Squeak
> VM was implemented with a system clock based on local time (simple but
> definitely not correct).
>
> In the current state of affairs, it is probably a good idea to make delays
> behave reasonably with respect to wall clock time. But it should done with
> the understanding that saved delays are not likely to behave reasonably if
> they are awakened in another time zone, and they definitely will not behave
> reasonably if the delay happens to occur over a daylight savings time
> transition in the local time zone.
>
>> >On 7 August 2013 17:13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> >>
>> >>Delays being ultimately low-level objects I don't think wall-clock makes
>> >>sense for them. You would need a calendar object for that, IMHO.
>> >>
>
> 100% agreed, but a cleaner solution is to use UTC rather than wall-clock for
> the underlying clock ticker. Once that is done, a whole host of bugs will
> go away, and it will be possible for low level objects to assume that time
> is a magnitude, not a hodge-podge of discontinuous values based on calendars.
>
> Dave
>
>
>>
>> On 8/7/13 12:28 PM, Frank Shearar wrote:
>> >At any rate my point is that Delays across image saves have caused
>> >Pharo people a reasonable amount of pain. If someone experiences pain,
>> >it can be worthwhile learning from the lessons of others.
>> >
>> >That is all.
>> >
>> >frank
>> >
>> >On 7 August 2013 17:13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> >>... which is not what Igor was proposing there, and I agree with Eliot's
>> >>objection to simply firing all delays at image startup time.
>> >>
>> >>Switching to wall-clock for all delays would have pretty much the same
>> >>effect, since the typical time between image snapshot and startup is
>> >>larger than the typical delay time.
>> >>
>> >>Delays being ultimately low-level objects I don't think wall-clock makes
>> >>sense for them. You would need a calendar object for that, IMHO.
>> >>
>> >>- Bert -
>> >>
>> >>On 2013-08-07, at 17:52, Frank Shearar <frank.shearar at gmail.com> wrote:
>> >>
>> >>>Well, it's at least partially here:
>> >>>http://forum.world.st/A-matter-with-Delays-td4671239.html People there
>> >>>seem to be proposing what's in this thread: sometimes what you mean is
>> >>>"15 minutes from now, wall clock time, do this", and other times you
>> >>>want "15 minutes from now, 'logical time', do this". "Logical time"
>> >>>means image running time.
>> >>>
>> >>>Personally, I'm in the wall-clock-is-all-there-is camp, for what it's
>> >>>worth.
>> >>>
>> >>>frank
>> >>>
>> >>>On 7 August 2013 16:40, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> >>>>Err, no? I don't have time to follow all mailing lists, rather relying
>> >>>>on kind people forwarding relevant discussions here :)
>> >>>>
>> >>>>- Bert -
>> >>>>
>> >>>>On 2013-08-07, at 17:36, 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
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >
>>
>
>>
>
>


More information about the Squeak-dev mailing list