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:
> 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 |
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 <[hidden email]>
|
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 <[hidden email]> > >> 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 >> >> > |
Free forum by Nabble | Edit this page |