On 18.02.2016, at 12:33, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Marcel,
On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel <Marcel.Taeumel@hpi.de mailto:Marcel.Taeumel@hpi.de> wrote: Hi, there!
The VM seems to "cache" the wall clock. This is weird.
Here is the story: I just booted into Windows and my time was wrong. Seems to be come Surface bug. It still was at the sleep time yesterday evenening, 11pm.
Squeak was already open, reporting the same.
Then, I updated the system time by letting Windows sync with Microsofts time server.
And then, the still running Squeak VM reported still the old values!!! :-/ How can that happen?
By my having coded time management in the Windows VM wrong? Look at sqWin32Heartbeat.c. This all needs rewriting anyway given the discussion on monotonic vs wall time. I'd like to have one copy of the code that computes the VM's notion of time, perhaps written in Smalltalk, and place that above platform-specific code that answers the monotonic and wall clocks.
But what should the VM do if it is faced with a huge jump in the time? Let's say that for testing you set the clock on your machine to 1970, then you started Smalltalk, and then you enabled syncing with the time server and the clock jumped forward to 2016. One could have the VM try to compensate but I think the best thing is to say "don't do that" and require teh user to restart their image. It's reasonable for the VM to maintain a clock that undergoes ntpd-like adjustments. It's complicated to have the VM try and distinguish small ntpd-like adjustments form huge adjustments in the clock. And keeping it simple seems like the best solution.
Why can’t we simply decouple the low-precision wall-clock from the high-precision monotonic clock used for timing? Marcel’s use case isn’t that unusual. I put my machine to sleep with images open all the time. That should work without having to restart the image.
- Bert -