[squeak-dev] DateAndTime>>startUp:

Levente Uzonyi leves at elte.hu
Thu Jan 27 22:01:46 UTC 2011


On Thu, 27 Jan 2011, Denis Kudriashov wrote:

> I found that initializeOffsets method setUp many class vars of DateAndTime.
> And it is ot thread safe. For example, DateAndTime>>now method can change

It _is_ thread safe. DateAndTime class >> #now sends 
#milliSecondsSinceMidnight to itself first. That sends #waitForOffsets 
also to itself first. And #waitForOffsets will block the current thread 
until the offsets are invalid by the forked thread.

So before the process executing #now could do anything, it will wait till 
the process running #initializeOffsets finishes.

This means that if a #startUp: method sends #now to DateAndTime "somehow", 
then it will bring back the max 1 second delay. But there's no such method 
in Squeak 4.2.

> some class vars when it's not initialized properly yet.
> And there is no guarantee that another registered startUp method does not
> corrupt some DateAndTime class state.
> Maybe cuis version takes into account this posible issues. Now I just
> removed fork in DateAndTime>>startUp method and send fixed application for
> testing.

I doubt the code is different in Cuis, since that's where we ported it from.

>
> Another question:
> Why DateAndTime so complex? Why DateAndTime>>now does not return OS api
> value from some simple primitive?

I don't know the correct answer, but I guess not all OSes have such 
feature. And (some) Smalltalk users like to do as much in Smalltalk as 
possible. :)

I'd like to have a clock with microsecond accuracy, but no OS seems to 
provide that. ;)


Levente

>
> 2011/1/27 Levente Uzonyi <leves at elte.hu>
>
>> On Thu, 27 Jan 2011, Denis Kudriashov wrote:
>>
>>  Why initializeOffsets executes by fork in startUp method?
>>>
>>> startUp: resuming
>>>   resuming ifFalse: [ ^ self ].
>>>   [     self initializeOffsets.] fork
>>>
>>>
>>> Cuise has this version:
>>>
>>> startUp: resuming
>>>   resuming ifFalse: [ ^ self ].
>>>   OffsetsAreValid _ false.
>>>   [
>>>       self initializeOffsets.
>>>       OffsetsAreValid _ true
>>>   ] forkAt: Processor userInterruptPriority.
>>>
>>>
>>> Why not just
>>>
>>> startUp: resuming
>>>   resuming ifFalse: [ ^ self ].
>>>   self initializeOffsets.
>>>
>>> ?
>>>
>>> I have appilcation. And sometimes when I run squeak I have bad dateTime
>>> equal to last saved value.
>>>
>>> I cant reproduced it manually.
>>> Can it be due wrong squeak implementation?
>>>
>>>
>> You didn't state it explicitly, but I found out that you're using Squeak
>> 4.1. In Squeak 4.2 we have the Cuis version of this method. But your issue
>> is unrelated. The change from Cuis makes the startup process faster by
>> forking #initializeOffsets. #initializeOffsets causes an at most 1 second
>> pause which is avoided by this "trick".
>>
>>
>> Levente
>>
>>
>



More information about the Squeak-dev mailing list