Hi Jaromir,

sorry for the late reply! I very much appreciate your feedback on these
things. :-)

Just for clarification, under normal circumstances, #isTerminated seems to
work as expected. If you debug the UI process (e.g., by evaluating "self
halt"), both the process being debugged and the debugging process answer
#false when sent #isTerminated.

The only exception from this rule appears to occur when the Processor >>
#evaluate:onBehalfOf: logic does not get unwound correctly so the
effectiveProcess is not reset, which is a consequence of the bug I described
in [1]. Unfortunately, there is even another way to reproduce this problem
by corrupting the stack of the simulated process and then debugging it using
#runUntilErrorOrReturnFrom:, for instance by stepping over a method that
does "thisContext privSender: nil" - see also [2] about this concern. In
this situation, a "cannot return" error is shown and after terminating it,
the debugged process keeps answering false when sent #isTerminated. I think
this is also related to the thread you started in [3]. Let's continue
discussing these issues in the relevant threads - I'll add my two cents
there soon!

However, nothing of these issues is a regression of the changeset proposed
in this thread. :-) We only renamed a few things (activeProcess to
genuineProcess) and refactored the accessors, but the conceptional logic of
process-faithful debugging has not been changed.

Still, missing resets of the effectiveProcess are indeed a general problem,
and at least in the event of a #cannotReturn:, there is no chance to unwind
#evaluate:onBehalfOf: properly. While we should fix the actual simulation
issues, I wonder whether we can and whether we should find a way to heal
processes again after a missing reset. A simple heuristic could be setting
the effectiveProcess to nil in every process that does not have an
#evaluate:onBehalfOf: context on its stack. Hypothetically, we could install
a workaround for this check in #isTerminated. Thinking more radically, we
could also replace the effectiveProcess variable with a stateless scoping
exception analogously to CurrentReadOnlySourceFiles, but this would affect
performance. Also, I'm not sure whether a process is automatically
invalidates as soon as the #evaluate:onBehalfOf: disappears from its stack
during simulation - just think of coroutines as used by the Generator,
probably they would be a legal operation as long as #evaluate:onBehalfOf:
will appear on the stack again at the end of the simulation. Questions over
questions ... Maybe you have some other good ideas here. :-)

Best,
Christoph

[1]
http://forum.world.st/Bug-in-Process-gt-gt-terminate-Returning-from-unwind-contexts-td5127570.html
[2]
http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-gt-gt-nextPut-td5108125.html
[3]
http://forum.world.st/Refactoring-terminate-to-get-rid-of-cannot-return-errors-etc-td5127732.html



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html