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
