Hi Jaromir,

> The main difference between your non-local example:
> 
> [self error: 'e1'] ensure: [^2]
> 
> and my one without the non-local return:
> 
> [self error: 'e1'] ensure: [self error: 'e2']
> 
> is that in your case the ^2 interrupts the orderly unwinding/termination
> and the UI process continues as if still in simulation (because of the
> missed effective process reset) - until another exception happens
> *somewhen* in the future - while in my examples the next exception
> resetting the effectiveProcess happens right away in the ensure block,
> presenting "only" the Unwind error on the outside.

Very precisely. For this reason, I suggest leaving aside my non-local return
example for the moment and focusing on your much simpler case instead. :-)

I have been sleeping over these problems a few times ... It seems strange to
me that the termination logic needs to involve a send to
#runUntilErrorOrReturnFrom: at all (also via #popTo:). This is usually meant
to be used by the debugger only (that's also why it has this special return
value format). In the current Trunk, the behavior of
#runUntilErrorOrReturnFrom: to catch UnhandledErrors is not even used at all
in #terminate (though I added rudimentary support to it in my previous
changeset). I have the feeling that we should not catch UnhandledErrors in
this place at all since there is not any present debugger that would process
these errors. Ideally, I would like to just hand over control to the process
to be terminated and have it unwind the entire stack down to the bottom
context.

Again from a rather conceptual point of view: How useful is it to terminate
a process "remotely", i.e. simulating it from the outside? Intuitively, I
would rather have said that terminating a process is a request to the
process to "please stop everything you are just doing and only unwind your
current operations". Why can't we just activate the relevant return context
on the process (see #popTo:) and then resume it again? Then everything
exceptional that might happen during the unwinding would behave exactly like
if the process weren't being unwound right now. The difference, though,
would be that the #terminate would return before the process would be
unwound, and we would need to rethink the priority of the process to be
terminated. For example, we could give it the priority of the active process
+ 1 or, in the worst case, use busy waiting in #terminate until the process
is terminated. Probably these considerations have been the reason to
implement #terminate in the current way. But conceptionally, wouldn't such
an approach be closer to the conceptual meaning of terminating a process?

Just thinking aloud ... I'm looking forward to your opinion! :-)

> This scenario, however uncovers a weakness in the #isTerminated, reporting
> the currently executing process with effectiveProcess assigned, as
> terminated and as a result preventing Process Browser to reveal such a
> pathological situation (which is precisely when you need to see it).

I don't think so ... The violated invariant in this situation is that the
effectiveProcess variable has not been reset. In general, Process >>
#isTerminated should indeed consider the effectiveProcess. Debugging
"Processor activeProcess isTerminated" should always work exactly like
executing it outside the debugger. :-)

Best,
Christoph



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