On Wed, 3 Mar 2010, Andreas Raab wrote:

> 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.

That shows my lack of knowledge about how the debugger works.

>
>> 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.

I'm only saying that normal usage (aka #terminate) shouldn't do 
unexpected things like this.
If you read the comment of Process >> #terminate, you may assume that 
#ensure: and #ifCurtailed: blocks will be excuted even if you use 
#terminate, but that's not true.

"Stop the process that the receiver represents forever.  Unwind to execute 
pending ensure:/ifCurtailed: blocks before terminating."


Levente

>
> Cheers,
>  - Andreas
>
>