On Thu, 4 Mar 2010, Nicolas Cellier wrote:

> 2010/3/3 Levente Uzonyi <leves at elte.hu>:
>> 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
>>
>
> The only way I see to solve your problem would be to execute the
> unwind block in another process...
> Quite technical and costly !

It's our problem. Just look at the senders of #ensure: and imagine what 
will happen if the termination block is not evaluated.
I think there's another way (though it might be my lack of knowledge 
again). After suspending the process which is about to be terminated we 
can check if it's executing a termination block. It it's not, we are safe 
to continue the termination, otherwise we can do something else which 
ensures that the termination block is evaluated.


Levente

>
> Nicolas
>
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>
>>
>
>