<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="Georgia">Interesting question. Is the presumption that
      everyone reading the Squeak list also reads the Pharo list? I, for
      one, do not.<br>
      <br>
      Cheers,<br>
      Bob<br>
      <br>
    </font>
    <div class="moz-cite-prefix">On 8/7/13 11:36 AM, Frank Shearar
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJbhyRGBaMftLCtstAh1sMjrcP86KE_EEFqNU_GztzXQHJVJ6A@mail.gmail.com"
      type="cite">
      <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:bert@freudenbergs.de">&lt;bert@freudenbergs.de&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:arning315@comcast.net">&lt;arning315@comcast.net&gt;</a> 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&gt;&gt;preSnapshot
"convert from local millisecond clock to milliseconds since Jan. 1 1901"
pendingDelay _ resumptionTime - Time millisecondClockValue.
resumptionTime _ Time totalSeconds * 1000 + pendingDelay

Delay&gt;&gt;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 <a class="moz-txt-link-rfc2396E" href="mailto:arning315@comcast.net">&lt;arning315@comcast.net&gt;</a> 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 "&lt;-----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; <a class="moz-txt-link-abbreviated" href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a class="moz-txt-link-freetext" href="http://www.rowledge.org/tim">http://www.rowledge.org/tim</a>
Strange OpCodes: YVR: Branch to Vancouver
















</pre>
      </blockquote>
      <pre wrap="">

</pre>
    </blockquote>
    <br>
  </body>
</html>