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

Levente Uzonyi leves at elte.hu
Thu Mar 4 00:06:37 UTC 2010


On Thu, 4 Mar 2010, Nicolas Cellier wrote:

> 2010/3/4 Levente Uzonyi <leves at elte.hu>:
>> 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.
>>
>
> Maybe...
> Unfortunately, you did not tell how you will distinguish well behaved
> unwind-blocks from Igor's example...

I'd give the responsibility to the developer to write termination blocks 
which are safe to evaluate. So I assume that all such blocks behave well. 
If something goes wrong you can kill the process with a more aggressive
method (as Andreas suggested), but you lose the guarantee that the current
termination block will be evaluated.


Levente

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


More information about the Squeak-dev mailing list