timing problem

Hi,
i ran a program that did some calculations for about an hour. in between
i occasionally moved the cursor (so that the computer did not go to
sleep) and probably clicked occasionally on the browser. after some time
this resulted in several errors from the browser (the program itself
does nothing with the browser). when i tried to reproduce this, the
program ran flawlessly (i retried it in 4.0., as i thought it happened
there but perhaps it happened in 3.0, and btw it was much faster in 4.0
than in earlier versions). now i wonder whether i should regularly cede
some time to other processes, and if yes, how does one do that?
werner

Werner Kassens wrote:
Just to be clear, by "did some calculations for an hour" do you mean the
Image basically locked up during the calculation, and the mouse clicks
were queued until the calculation ended?

Anyhow, there are two general approaches I am familiar with.
1. Add " Processor yield " within your calculation loop.
2. Run your calculation at a priority lower than the UI. For example, "
result := nil. calculationProcess := [ result := self myCalculation ]
forkAt: Processor userBackgroundPriority " , then periodically test for
" result ~= nil " , maybe from a "step" method in your own subclass of
some Morph.

cheers -ben

Hi,

On 09/06/2014 03:35 PM, Ben Coman wrote:

> Just to be clear, by "did some calculations for an hour" do you mean the
> Image basically locked up during the calculation, and the mouse clicks
> were queued until the calculation ended?

exactly, after the calculation different windows spring into the
foreground, if i redo that. the strange thing though is, that the
errormessages came during the calculation and although (they added up
fast) i did not really look at them (i just cklicked them away, after
having interrupted the program) in the end they originated from the browser.

> Anyhow, there are two general approaches I am familiar with.
> 1. Add " Processor yield " within your calculation loop.
> 2. Run your calculation at a priority lower than the UI. For example, "
> result := nil. calculationProcess := [ result := self myCalculation ]
> forkAt: Processor userBackgroundPriority " , then periodically test for
> " result ~= nil " , maybe from a "step" method in your own subclass of
> some Morph.

and what do i do after 'result ~= nil' ? <stupid grin>
and what is the disadvantage of the simple first solution, i have to
admit i never looked at these fork things?
werner

Werner Kassens wrote:
Sorry, I can't tell across email if that <stupid grin> is
tongue-in-cheek since you know exactly what to do, or you are looking
for advice :)
It depends... How would you deal with the result of your calculation
(assuming you didn't fork it)?

In very general terms you'd have
MyMorph>>step
    (result ~= nil) ifTrue: [
       "do stuff to update my 'StringMorph' submorphs with result data I
now have"
       "or do stuff to write results to disk or database, and display
'FINISHED', and sound a beep"
     ]



> and what is the disadvantage of the simple first solution, i have to
> admit i never looked at these fork things?
> werner
>
>

I'm not sure if there is any practical disadvantage**. Again, it
depends...  on how tight your loops are, and exactly where you put the
"Processor yeilds".  You'd need to suck-it-and-see.  But speaking
generally, you calculation is still competing with the UI loop.  If you
yield every 100ms and you click the mouse immediately after the
calculation starts, then the click will** not be seen by the UI for
100ms, so you will see some lag.  There may be downsides to yielding
more often**, and it may take some effort to determine cycle period of
various parts of your loops to get it working smoothly, if even these
remain consistent across the life and use of your application.

With the second approach, any mouse click will interrupt the calculation
and be handled immediately** so its likely the UI will remain more
responsive.  With the second approach, it is also easier to suspend and
continue the calculation, if you so desired.

** These are my beliefs I've picked as I've looked into some parts of
Pharo internals, but I don't know enough to be sure.  Others might
correct me.
cheers -ben

 > Sorry, I can't tell across email if that <stupid grin> is
 > tongue-in-cheek since you know exactly what to do, or you are looking
 > for advice :)

Hi Ben,
i did not want to irritate you, i just thought perhaps i need to do some
sort of clean up with that fork thing afterwards (like deleting a
process or whatever), but your answer makes it clear that this is not
necessary. many thanks for your detailed answer, i guess i can deal with
the problem now.
werner

Werner Kassens wrote:
No problem at all.  btw, I wasn't irritated (maybe just another example
of limits of email), just letting you know I was uncertain as to what
you required.
Looking forward to your next questions.
cheers -ben