On 26 December 2010 01:12, Eliot Miranda <
[hidden email]> wrote:
>
>
>
> On Sat, Dec 25, 2010 at 12:20 PM, Igor Stasenko <
[hidden email]> wrote:
>>
>> On 25 December 2010 16:56, Mariano Martinez Peck <
[hidden email]> 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. :)
--
Best regards,
Igor Stasenko AKA sig.
Locked
