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.


> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100303/f425f1b7/attachment.htm