DateAndTime>>startUp:

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?

On Thu, 27 Jan 2011, Denis Kudriashov wrote:

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

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?

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