Hi Christoph,

> IMHO, when terminating a process, halfway-executed unwinded contexts
> should not be continued. Only not-yet-activated unwind contexts should be
> triggered.


Yes, I too was wondering why there are different unwind semantics in various
situations (error handling, active process unwind, active and suspended
process termination); why there's not just one common semantics for all. My
conclusion was completing half-ways through unwind blocks was way more
complex than unwinding just the not-yet-started unwind blocks.

As a result (my opinion) Squeak implemented just the completion of the most
recent half-ways through unwind block during termination, and VisualWorks
went a step further and implemented the completion of the outer-most
half-ways through unwind block.

Both however left the termination of the active process on the basic level -
no completion of half-ways through blocks. In my attempt I proposed to unify
the semantics of active process and suspended process termination by
suspending the active process and terminating is as a suspended process.

I was considering a fun discussion about extending the error handling and
unwind semantics to match the termination unwind semantics - i.e. including
completion of half-ways through unwind blocks during normal returns - but
that's most likely in the "way too clever" territory :)

Your proposition goes in the opposite direction however - to reduce the
termination semantics to match the current error handling and active process
unwind semantics.

Well, I personally prefer completing the half-ways through unwind blocks
where possible. In my mind it means "try to repair or clean-up as much as
possible before ending a process". I still think completing half-ways
through unwind blocks is worth the extra effort.

Regarding the example:


> [
> 	[
> 		[
> 			[ ] ensure: [ "halfway through completion"
> 				[ ] ensure: [ "halfway through completion"
> 					self error. 
> 					x1 := true]. 
> 				x2 := true]
> 		] ensure: [ "not started yet"
> 			x3 := true]
> 	] on: Error do: []
> ] fork
> {x1 . x2 . x3} ---> #(nil nil true) 
>
> In my view, process termination should have exactly the same semantics as
> using an exception to abort the control flow.
> If we would not catch the error in the above example but press Abandon in
> the appearing debugger instead, I see no reason why we would want to
> execute a different set of unwind contexts.

I disagree here: If we would not catch the error, we would be in a different
situation: an error would have occurred which we would not have anticipated,
thus abandoning the debugger would be a different intentional action than a
controlled and anticipated return from an exception. I may argue we could
even attempt to unwind as if terminating but I'm not sure it'd be justified.
So actually I must admit a different semantics here may even be desirable.
I'm not sure in this regard.

So to conclude, unification was my original driver but I'm no longer so
sure... Termination may be a different beast than a regular return or
handled error after all.

Thanks for this discussion, I look forward to taking a closer look at your
changeset!

Hi Nicolas,


Nicolas Cellier wrote
> Hi Christoph,
> I guess that the original intention was to perform the cleanup (like
> releasing resources) even if we close the debugger in the midst of
> unwinding.
> Whether this is a good idea or not is questionable indeed if the debugger
> was opened due to unhandled error during execution of unwind block.
> But the debugger was not necessarily opened during unwinding...
> The question you raise is whether we are trying to be too much clever...
> It
> might be.

Yes indeed, trying to be too clever is very dangerous!! I'm old enough to
know first hand :D
Thanks,

best,




-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html