I notice...
DebugSession >> resumeProcess
"Make sure the interrupted process is restored properly and restart the low space handler"
interruptedProcess isTerminated
ifFalse: [
errorWasInUIProcess
ifTrue: [ UIManager default resumeUIProcess: interruptedProcess ]
ifFalse: [ interruptedProcess resume ]].
"restart low space handler"
Smalltalk installLowSpaceWatcher.
and...
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.
testUserPriority
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
Locked
