reinstating original UI thread after debugging

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

reinstating original UI thread after debugging

Ben Coman
I notice...

DebugSession >> resumeProcess
    "Make sure the interrupted process is restored properly and restart the low space handler"
interruptedProcess isTerminated
ifFalse: [ 
ifTrue: [ UIManager default resumeUIProcess: interruptedProcess ]
ifFalse: [ interruptedProcess resume ]].

"restart low space handler"
Smalltalk installLowSpaceWatcher.

MorphicUIManager >> resumeUIProcess: aProcess
"Adopt aProcess as the project process -- probably because of proceeding from a debugger"
UIProcess := aProcess.
UIProcess resume

This doesn't seem to do anything regarding the second UI process spawned in...
MorphicUIManager >> debugProcess:context:label:fullView:notification:

With Process Browser running with auto-update on, 
running the following experiment confirms that the second spawned UI is killed.

   TestCase subclass: #Example2

   Example2 >> test1
      Processor activeProcess name: 'ORIGINAL UI'.
self halt    

So I'm curious, where is the code killing the second UI ?

Also curious, when the first UI turns into a debuggger, 
why later reinstate the first UI and kill the second UI?
If the second UI started clean and is running happily, why not leave it running 
and let first UI thread terminate normally? 

I get some strange behaviour** sometimes , and wonder if the swap back it might be related to this. 

** Like today #testUserPriority below not opening a debugger at the first halt statement, or opening a pre-debug window that has a blank pane.

debug := true.
Processor activeProcess priority: 38.
self halt.
highPriorityProcess := self highPriorityRunLoop.
Transcript cr.
debug ifTrue: [self halt].
3 timesRepeat: [ 
Transcript crShow: 'U'. 
self wakeHighPriorityLoop.].
highPriorityProcess terminate.

cheers -ben