[squeak-dev] Re: [Pharo-project] #ensure: issues

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Mar 4 00:45:14 UTC 2010

2010/3/4 Eliot Miranda <eliot.miranda at gmail.com>:
> 2010/3/3 Andreas Raab <andreas.raab at gmx.de>
>> On 3/3/2010 2:07 PM, Levente Uzonyi wrote:
>>> On Wed, 3 Mar 2010, Igor Stasenko wrote:
>>>> i don't get it. Just before that, you said: ' I'd expect it to be
>>>> evaluated no matter what happens.' ?
>>>> But now you saying that it may not be executed in some conditions
>>>> (when user pressing abandon button, causing process to be terminated).
>>> It's simple: don't terminate process X from another process if process X
>>> is executing a termiation block (aka #ensure: block). Or if you
>>> terminate it, make sure that the execution of the block will continue
>>> somehow (I don't care how).
>> You're missing Igors point which is that in his example the halt /
>> Transcript *was* in the ensure block and as a result you're contradicting
>> yourself here. Let's go back to Igor's example:
>> [self boom ] ensure: [ self halt. Transcript show: 'boom']
>> The halt is inside the ensure block. If you terminate the process from the
>> debugger, it would be logical from your statement that the Transcript
>> message would be executed - after all it's " executing a termiation block
>> (aka #ensure: block)" and so it can't be terminated by your reasoning.
>> However, when Igor was pointing this out you replied with "I didn't say
>> that. I said evaluate it the same way as normal code." which is inconsistent
>> with the other statement.
>>> I think every user of #ensure: expects that the termination blocks are
>>> executed even if the process which is executing the receiver of #ensure:
>>> is terminated. And it actually happens in all but this case.
>> The question of terminating processes is always tricky. I don't think that
>> your proposal would actually work in practice - it could easily result in
>> processes that cannot be terminated due to a simple bug in an ensure block.
>> Personally, I'd rather say that the more useful behavior would be something
>> along the lines of saying that process termination either skips the current
>> ensure block (assuming there's a bug and it should get the heck out of it
>> but try to evaluate the remaining ones) or that there need to be two
>> terminations - one that is 'soft' and won't allow ensure blocks to be
>> skipped and one that is 'hard' (kill -9 hard) and just ignores all the
>> ensure blocks.
> That's what we did in VisualWorks.  Normal terminate is as you say.  It
> tries to run unwinds until an error, and then if necessary one wields
> terminateWithExtremePrejudice and kills the thing stone dead.

Fun name.
I just imagine a terminateWithGradualPrejudice that would step to next
unwind block in case of error...


>> Cheers,
>>  - Andreas

More information about the Squeak-dev mailing list