<br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 5:30 PM, Gary Chambers <span dir="ltr"><<a href="mailto:gazzaguru2@btinternet.com">gazzaguru2@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Certainly a tangled web... of course we want all ensures to happen,<br>
like, I think, any use of terminate to happen too. A conflict of<br>
interest, especially in the case of errors within ensures...<br>
<br>
No easy answer I think. I favour having terminate complete if errors in<br>
ensures, otherwise that ensures complete before eventual termination...<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards, Gary<br>
<div><div></div><div class="h5"><br>
<br>
On Thu, 2010-03-04 at 00:56 +0100, Nicolas Cellier wrote:<br>
> 2010/3/4 Levente Uzonyi <<a href="mailto:leves@elte.hu">leves@elte.hu</a>>:<br>
> > On Thu, 4 Mar 2010, Nicolas Cellier wrote:<br>
> ><br>
> >> 2010/3/3 Levente Uzonyi <<a href="mailto:leves@elte.hu">leves@elte.hu</a>>:<br>
> >>><br>
> >>> On Wed, 3 Mar 2010, Andreas Raab wrote:<br>
> >>><br>
> >>>> On 3/3/2010 2:07 PM, Levente Uzonyi wrote:<br>
> >>>>><br>
> >>>>> On Wed, 3 Mar 2010, Igor Stasenko wrote:<br>
> >>>>>><br>
> >>>>>> i don't get it. Just before that, you said: ' I'd expect it to be<br>
> >>>>>> evaluated no matter what happens.' ?<br>
> >>>>>> But now you saying that it may not be executed in some conditions<br>
> >>>>>> (when user pressing abandon button, causing process to be terminated).<br>
> >>>>><br>
> >>>>> It's simple: don't terminate process X from another process if process<br>
> >>>>> X<br>
> >>>>> is executing a termiation block (aka #ensure: block). Or if you<br>
> >>>>> terminate it, make sure that the execution of the block will continue<br>
> >>>>> somehow (I don't care how).<br>
> >>>><br>
> >>>> You're missing Igors point which is that in his example the halt /<br>
> >>>> Transcript *was* in the ensure block and as a result you're<br>
> >>>> contradicting<br>
> >>>> yourself here. Let's go back to Igor's example:<br>
> >>>><br>
> >>>> [self boom ] ensure: [ self halt. Transcript show: 'boom']<br>
> >>>><br>
> >>>> The halt is inside the ensure block. If you terminate the process from<br>
> >>>> the<br>
> >>>> debugger, it would be logical from your statement that the Transcript<br>
> >>>> message would be executed - after all it's " executing a termiation<br>
> >>>> block<br>
> >>>> (aka #ensure: block)" and so it can't be terminated by your reasoning.<br>
> >>>> However, when Igor was pointing this out you replied with "I didn't say<br>
> >>>> that. I said evaluate it the same way as normal code." which is<br>
> >>>> inconsistent<br>
> >>>> with the other statement.<br>
> >>><br>
> >>> That shows my lack of knowledge about how the debugger works.<br>
> >>><br>
> >>>><br>
> >>>>> I think every user of #ensure: expects that the termination blocks are<br>
> >>>>> executed even if the process which is executing the receiver of<br>
> >>>>> #ensure:<br>
> >>>>> is terminated. And it actually happens in all but this case.<br>
> >>>><br>
> >>>> The question of terminating processes is always tricky. I don't think<br>
> >>>> that<br>
> >>>> your proposal would actually work in practice - it could easily result<br>
> >>>> in<br>
> >>>> processes that cannot be terminated due to a simple bug in an ensure<br>
> >>>> block.<br>
> >>>> Personally, I'd rather say that the more useful behavior would be<br>
> >>>> something<br>
> >>>> along the lines of saying that process termination either skips the<br>
> >>>> current<br>
> >>>> ensure block (assuming there's a bug and it should get the heck out of<br>
> >>>> it<br>
> >>>> but try to evaluate the remaining ones) or that there need to be two<br>
> >>>> terminations - one that is 'soft' and won't allow ensure blocks to be<br>
> >>>> skipped and one that is 'hard' (kill -9 hard) and just ignores all the<br>
> >>>> ensure blocks.<br>
> >>><br>
> >>> I'm only saying that normal usage (aka #terminate) shouldn't do<br>
> >>> unexpected<br>
> >>> things like this.<br>
> >>> If you read the comment of Process >> #terminate, you may assume that<br>
> >>> #ensure: and #ifCurtailed: blocks will be excuted even if you use<br>
> >>> #terminate, but that's not true.<br>
> >>><br>
> >>> "Stop the process that the receiver represents forever. Unwind to<br>
> >>> execute<br>
> >>> pending ensure:/ifCurtailed: blocks before terminating."<br>
> >>><br>
> >>><br>
> >>> Levente<br>
> >>><br>
> >><br>
> >> The only way I see to solve your problem would be to execute the<br>
> >> unwind block in another process...<br>
> >> Quite technical and costly !<br>
> ><br>
> > It's our problem. Just look at the senders of #ensure: and imagine what will<br>
> > happen if the termination block is not evaluated.<br>
> > I think there's another way (though it might be my lack of knowledge again).<br>
> > After suspending the process which is about to be terminated we can check if<br>
> > it's executing a termination block. It it's not, we are safe to continue the<br>
> > termination, otherwise we can do something else which ensures that the<br>
> > termination block is evaluated.<br>
> ><br>
><br>
> Maybe...<br>
> Unfortunately, you did not tell how you will distinguish well behaved<br>
> unwind-blocks from Igor's example...<br>
><br>
> Nicolas<br>
><br>
> ><br>
> > Levente<br>
> ><br>
> >><br>
> >> Nicolas<br>
> >><br>
> >>>><br>
> >>>> Cheers,<br>
> >>>> - Andreas<br>
> >>>><br>
> >>>><br>
> >>><br>
> >>><br>
> >><br>
> ><br>
> ><br>
> ><br>
> ><br>
><br>
<br>
<br>
<br>
</div></div></blockquote></div><br>