<br><br><div class="gmail_quote">2010/3/3 Andreas Raab <span dir="ltr">&lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 3/3/2010 2:07 PM, Levente Uzonyi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 3 Mar 2010, Igor Stasenko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i don&#39;t get it. Just before that, you said: &#39; I&#39;d expect it to be<br>
evaluated no matter what happens.&#39; ?<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>
</blockquote>
<br>
It&#39;s simple: don&#39;t terminate process X from another process if process 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&#39;t care how).<br>
</blockquote>
<br>
You&#39;re missing Igors point which is that in his example the halt / Transcript *was* in the ensure block and as a result you&#39;re contradicting yourself here. Let&#39;s go back to Igor&#39;s example:<br>
<br>
[self boom ] ensure: [ self halt. Transcript show: &#39;boom&#39;]<br>
<br>
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&#39;s &quot; executing a termiation block (aka #ensure: block)&quot; and so it can&#39;t be terminated by your reasoning. However, when Igor was pointing this out you replied with &quot;I didn&#39;t say that. I said evaluate it the same way as normal code.&quot; which is inconsistent with the other statement.<br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think every user of #ensure: expects that the termination blocks are<br>
executed even if the process which is executing the receiver of #ensure:<br>
is terminated. And it actually happens in all but this case.<br>
</blockquote>
<br>
The question of terminating processes is always tricky. I don&#39;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&#39;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&#39;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 &#39;soft&#39; and won&#39;t allow ensure blocks to be skipped and one that is &#39;hard&#39; (kill -9 hard) and just ignores all the ensure blocks.<br>
</blockquote><div><br></div><div>That&#39;s what we did in VisualWorks.  Normal terminate is as you say.  It tries to run unwinds until an error, and then if necessary one wields terminateWithExtremePrejudice and kills the thing stone dead.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
  - Andreas<br>
<br>
</font></blockquote></div><br>