Certainly a tangled web... of course we want all ensures to happen,
like, I think, any use of terminate to happen too. A conflict of
interest, especially in the case of errors within ensures...

No easy answer I think. I favour having terminate complete if errors in
ensures, otherwise that ensures complete before eventual termination...

Regards, Gary


On Thu, 2010-03-04 at 00:56 +0100, 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...
> 
> Nicolas
> 
> >
> > Levente
> >
> >>
> >> Nicolas
> >>
> >>>>
> >>>> Cheers,
> >>>>  - Andreas
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>