On Wed, Mar 3, 2010 at 5:30 PM, Gary Chambers <gazzaguru2 at btinternet.com>wrote:

> 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...
>

I think it's vital that an error during termination is reported not
silenced.  How are you going to write something correct if errors during
termination are hidden?


>
> 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
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > >
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100303/6cc32767/attachment.htm