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 <holger@freyther.de> 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