Werner Kassens wrote:
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>
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
