<br><br><div class="gmail_quote">On Fri, Dec 2, 2011 at 8:17 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
There is only one possibly correct answer which is raising BlockCannotReturn, because we're trying to return while we're in the midst of returning already, so there is no place to return to. That answer is implemented by the attached change set.<br>
<br>
BTW, the code duplication between ContextPart>>restart ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate bothers me greatly. The change set only fixes one of these locations (the one triggered by your problem statement) but having such critical code duplicated all over the places can't be good. Any takers?<br>
</blockquote><div><br></div><div>The first thing is a good set of tests. Do we have some of them? Clearly we don't have them for this case. What's the scope of the tests?</div><div><br></div><div><span class="Apple-style-span">The second thing I find related is that I find ContextPart>jump incomprehensible and worrying. Using simulation machinery to advance execution just seems wrong with me and yet this code is used in process termination (via runUntilErrorOrReturnFrom:) and in exception handling (via ContextPart>restart). </span>ContextPart>jump<span class="Apple-style-span"> is extremely complex and slow and buggy (I recently (</span> eem 11/16/2011 10:58) <span class="Apple-style-span">found and fixed a bad bug in </span>runUntilErrorOrReturnFrom: that was causing too much peeling back of the stack in exception delivery when trying to advance a process to a particular point suitable for presenting to the user. If we could simplify this code that would be a relief to me :)</div>
<div><br></div><div>The third thing that is related is that if a process is terminated from a different process, then unwinds execute in the context of the process that initiated the termination, not the process being terminated.</div>
<div><br></div><div>The fourth thing that is related in my mind is that Cog supports a much faster Mutex which is in use in OpenQwaq and could be ported to Squeak and Pharo. But it needs some work on process termination, to avoid losing a signal when a process is terminated while in a critical section on the mutex. This is related because fixing this requires some work on unwind implementation.</div>
<div><br></div><div>I think all of these need addressing, but they shouldn't be conflated. I'm just writing them down here so they don't get forgotten.</div><div><br></div><div>cheers,</div><div>Eliot</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</font><div><div></div><div class="h5"><br>
<br>
On 12/2/2011 15:18, Tobias Pape wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear All,<br>
<br>
given the following class:<br>
<br>
Object subclass: #Foo<br>
instanceVariableNames: ''<br>
classVariableNames: ''<br>
poolDictionaries: ''<br>
category: 'Foo'!<br>
a<br>
self b: [^ 1].! !<br>
<br>
b: aBlock<br>
<br>
[self c: aBlock] ensure: [^ 2].<br>
<br>
c: aBlock<br>
<br>
aBlock value.<br>
^ 3<br>
<br>
And you would do<br>
<br>
Foo new a<br>
<br>
what would you expect?<br>
<br>
I am very curious.<br>
Please, first guess, then execute.<br>
<br>
Best<br>
-Tobias<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</div></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>