I am still struggling with it.Any ideas?
2014-07-09 11:19 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
2014-07-09 2:07 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolai,
On Tue, Jul 8, 2014 at 7:19 AM, Nicolai Hess <nicolaihess@web.de> wrote:
I want to create a process doing some work and call #changed on a Morph.
I want to start/suspend/resume or stop this process.
But sometimes, suspending the process locks the UI-Process,
and I don't know why. Did I miss something or do I have to care when to call suspend?
Wrapping the "morph changed" call in
UIManager default defer:[ morph changed].
Does not change anything.
Here is an example to reproduce it.
Create the process,
call resume, call supsend. It works, most of the time,
but sometimes, calling suspend locks the ui.
p:=[[true] whileTrue:[ Transcript crShow: (DateAndTime now asString). 30 milliSeconds asDelay wait]] newProcess.��p resume.
p suspend.
If you simply suspend this process at random form a user-priority process you'll never be able to damage the Delay machinery you're using, but chances are you'll suspend the process inside the critical section that Transcript uses to make itself thread-safe, and that'll lock up the Transcript.��
Thank you Eliot
yes I guessed it locks up the critical section, but I hoped with would not happen if I the use UIManager defer call.
��
ThreadSafeTranscript>>nextPutAll: valueaccessSemaphorecritical: [stream nextPutAll: value].^value
So instead you need to use a semaphore. ��e.g.
| p s wait |s := Semaphore new.p:=[[true] whileTrue:[wait ifTrue: [s wait]. Transcript crShow: (DateAndTime now asString). 30 milliSeconds asDelay wait]] newProcess.wait := true.30 milliSeconds asDelay wait.
wait := false.s signal
etc...
Is this a common pattern I can find in pharos classes. Or I need some help understanding this. The semaphore
wait/signal is used instead of process resume/suspend?
What I want is a process doing repeatly some computation,
calls or triggers an update on a morph, and I want to suspend and resume this process.
I would stop this discussion if someone tells me, "No your are doing it wrong, go this way ..",�� BUT what strikes me:
in this example, that reproduces my problem more closely:
|p m s running|
running:=false.
m:=Morph new color:Color red.
s:= StringMorph new.
m addMorphBack:s.
p:=[[true]whileTrue:[20 milliSeconds asDelay wait. s contents:(DateAndTime now asString). m changed]] newProcess.
m on:#mouseUp send:#value to:[
������ running ifTrue:[p suspend. m color:Color red.]
������ ifFalse:[p resume.m color:Color green.].
������ running := running not].
m extent:(300@50).
m openInWorld
clicking on the morph will stop or resume the process, if it locks up I can still press alt+dot ->
- a Debugger opens but the UI is still not responsive. I can click with the mouse on the debuggers close icon.
- nothing happens, as the UI is still blocked.
- pressing alt+Dot again, the mouse click on the close icon is processed and the first debugger window closes
- maybe other debuggers open.
Repeating this steps, at some time the system is *fully* responsive again!
And miraculously, it works after that without further blockages.What's happening here?
Nicolai
��
HTH
regardsNicolai
--
best,Eliot