I can't repeat this for now. I think we need a more precise definition of 'is not responsive'. Is it not handling events or not executing any code ? Maybe a loop/animation in the image that then clearly stops or even better, notices itself that something went wrong - I know I am asking for a lot ;-) On 13 Jan 2014, at 09:37, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:
Try the following on OS X...
1. Launch Pharo (Cuis).
2. Go to the System Settings time panel.
3. Disable automatic time updates.
4. Bump the clock forward by 1 minute.
5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen).
6. Wait one minute.
7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again).
As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute.
If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward.
I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images.
On 1/13/14 0:22 , Sven Van Caekenberghe wrote:
Hi Andres,
Could you describe in some detail how to make something clearly fail related to this issue ?
There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable.
Thx,
Sven
On 12 Jan 2014, at 04:41, Andres Valloud <avalloud@smalltalk.comcastbiz.net> wrote:
Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc.
BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds.
On 1/11/14 19:29 , Martin McClure wrote:
I'm beginning to suspect that delays are not expiring at the OS level
.