I found that initializeOffsets method setUp many class vars of DateAndTime.
And it is ot thread safe. For example, DateAndTime>>now method can change
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.

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

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110127/ad3d72ba/attachment.htm