Don't know about ANSI, but I would expect the process to be terminated before "Transcript show: 'done'" gets executed, and any ensure (or ifCurtailed) blocks above this method to be executed (probably in the process that calls #terminate).
Looking at BlockContext>>ensure:, it looks like your bug might be fixed by niling out aBlock before executing it (which would require that you access thisContext). Or, perhaps a better way is to add a new <primitive: 81> method to BlockContext that simply does nothing if the primitive fails...call it BlockContext>>#valueForUnwind, then make ContextPart>>unwindTo: use that method.
If you fix that bug, then it looks to me like it would do the expected thing.
- Stephen
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Sunday, June 30, 2002 2:02 PM To: squeak-dev@lists.squeakfoundation.org Subject: unwind behavior
Hi,
Just a question: Does anyone know what the *expected* behavior for terminating a process is where an unwind block is currently under evaluation?! E.g., a simple test case is:
process := [[3+4] ensure:[ Transcript cr; show: 'Unwinding...'. Processor activeProcess suspend. Transcript show:'done'. ]] fork. (Delay forMilliseconds: 100) wait. process terminate.
Right now this raises an error in Squeak (attempting to evaluate a block which is already evaluated) so this is clearly wrong. But what *is* the expected behavior in this case?! Does somebody know what ANSI has to say about this problem?
Cheers,
- Andreas
squeak-dev@lists.squeakfoundation.org