[squeak-dev] Re: [Pharo-project] #ensure: issues
leves at elte.hu
Wed Mar 3 22:54:53 UTC 2010
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."
> - Andreas
More information about the Squeak-dev