Hi Holger, I make an issue out of this (I hope you can access this):
https://pharo.fogbugz.com/f/cases/12893/100-CPU-usage-on-image-resume but... [ [ Transcript crShow: DateAndTime now. 5 seconds asDelay wait ] repeat ] fork. works for me (Pharo #30754, Mac OS X), so please, come up with a failing example, else I'll have to close the issue again. Sven On 13 Feb 2014, at 08:44, Holger Hans Peter Freyther <[email protected]> wrote: > On Wed, Feb 12, 2014 at 03:31:56PM +0100, Sven Van Caekenberghe wrote: >> Holger, > > Dear Sven, > > thanks a lot for your answer. > >>> The entire process list is below. My assumption is that the >>fireTimers: >>> method is actually being executed. The best thing I found was to use SIGUSR1 >>> to sample which processes run. My assumption is that this process runs >>> before >>> DateAndTime has been re-initialized by the SmalltalkImage. > > >> >> Now, you do agree that you are doing tricky stuff, right ? You play with >> timers, timestamps and delays in a process that you expect to keep running >> over image save/resume ;-) > > The timers work with absolute time and the code is working fine with GNU > Smalltalk for years (with image save/resume). I think the only thing weird > in Pharo is that (Delay forSeconds: 1) wait will wait forever on image > resume but IIRC this is a known issue/feature. > >> >> I think a better approach would be to subscribe to image #shutDown: and >> #startUp: events (trace these selectors for examples). With these you can >> cleanly stop your process on image save and restart it when the image >> resumes. I think all long running processes work that way. > > > I have implemented your proposal and I think the problem will go away > with that. To me this sounds a bit like a work-around. Do you agree? I > think something like: > > [[DateAndTime now] repeat] fork > > could re-produce the issue. It can either get stuck inside the Delay > created from within >>#now or in this mysterious loop that takes all the > CPU and doesn't allow me to interact with the image anymore. It would be > nice to fully understand why this process runs away and no other process > will be scheduled. > > I don't know how the ProcessorScheduler works in Pharo and when/if a > method is pre-empted. Is there any guarantee that the StartUpList will > be executed before any other process will be scheduled? From quick browsing > it seems that the SmalltalkImage code does not suspend all the other > processes? > > kind regards > holger >
