2010/3/4 Levente Uzonyi <leves at elte.hu>:
> 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/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
>>>
>>
>> I would tend to focus first on the senders of terminate since
>> terminating is unsafe...
>
> The comment suggest to me that it's safe to use it, because it will evaluate
> the termination blocks.
>

Yes, my question was wrong: is the trunk concerned with the problem ?
But it does not answer your question: how my own application could
terminate reliably.

Nicolas

>
> Levente
>
>> How many of them would deserve to be transformed in a terminateRequest ?
>>
>> Nicolas
>>
>>>>
>>>> Nicolas
>>>>
>>>>>
>>>>> Levente
>>>>>
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>  - Andreas
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>