[Vm-dev] asserta(newUtcMicrosecondClock >= utcMicrosecondClock)
siguctua at gmail.com
Sun Dec 26 00:59:48 UTC 2010
On 26 December 2010 01:12, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Sat, Dec 25, 2010 at 12:20 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> On 25 December 2010 16:56, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>> > Hi everybody. I hope you are enjoying a wonderful and happy Christmas.
>> > Yesterday something weird happened with my cog vm. This assert was failing:
>> > "newUtcMicrosecondClock >= utcMicrosecondClock 127"
>> > a lot of times...
>> > I checked and this is line 127 of sqUnixHeartbeat.c. I am in a MacOS vm, but it seems that file is used anyway.
>> > Now...I have no idea why this assert was failing, nor its severity. What does it mean? there is something wrong? where can I take a look?
>> if microseconds clock counter is 32-bit, then it wraps over time to time.
>> VM should be aware that this may happen and should take appropriate
>> measures (like adjusting the wait timeouts etc).
> The microsecond clock is 64-bit to avoid precisely the possibility of the clock wrapping within anything other than wildly optimistic predictions of the possible life of Smalltalk.
How about Eistein's special relativity? :)
A 64-bit clock wrap could happen within Smalltalk life time, if you
get enough speed.
>> > It seems it is not easy to reproduce :(
>> yeah, you should wait another
>> ~ 2^32 / 1000000 seconds
> By all means but you won't see it wrap.
it depends to what value is a counter were reset at a boot time.
You know, some nasty guys could set it to #FF FF FF FF FF FF 00 00
to intentionally spoil your optimistic expectations. :)
I would do that in my system. So developers will learn how to write a
64-bit-overflow proof code :)
But if seriously yeah.. it is hard to imagine what may cause 64-bit
counter to wrap. :)
Igor Stasenko AKA sig.
More information about the Vm-dev