<div dir="ltr">Hi Bert,<div><br></div><div> sorry. Got deep into something and have only just come up for air...</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 1:02 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="">On 01.04.2015, at 20:51, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><br>
> I would find it very surprising if #jump would result in the execution continuing in a different process.<br>
><br>
> That's not what they do. Instead they spawn another process to position the process in which we want to jump correctly.<br>
<br>
</div></div>We don't want to jump to a process but within a process, like a goto…<br></blockquote><div><br></div><div>Well, jump doesn't do unwinds so the code should be simply:</div><div><br></div><div><span style="font-size:13px"><div>jump</div><div><span style="white-space:pre-wrap"> </span>"Abandon thisContext and resume self instead (using the same current process)."</div><div><span style="white-space:pre-wrap"> </span><span>| process |</span><br></div></span><div style="font-size:13px"><span style="white-space:pre-wrap"> </span>process := Processor activeProcess.</div><div style="font-size:13px"><span style="white-space:pre-wrap"> </span>[process suspendedContext: self] fork.</div><div style="font-size:13px"><span style="white-space:pre-wrap"> </span>Processor yield</div></div></div></div></div></div></blockquote><br></div></span><div>Ah, I misread what you were proposing before. Simpler is better for understanding :)</div><div><br></div><div>Assuming there are more runnable processes at the active priority, could there be a scenario where the #jump context is resumed after the yield, before the forked process had a chance to run? Or would we have to fork it at a higher priority? Could either in any way mess with the order of process activation, which would not happen with the current #jump implementation?</div></div></blockquote><div><br></div><div>That depends. If the VM is /not/ in the processPreemptionYields regime (and I need to remember to put Spur images into this regime) then no, doing the fork at a higher priority cannot disturb processes. But if the process is forked at the same priority, or if the VM is in the processPreemptionYields regime, then yes, this can screw up process priorities.</div><div><br></div><div>So assuming</div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style><span style="font-size:13px;white-space:pre-wrap"> Smalltalk </span><span style="white-space:pre-wrap">processPreemptionYields: false</span></div></div></div></div></blockquote><div><div class="gmail_extra"><div class="gmail_quote"><div style><span style="white-space:pre-wrap">then the following is, I think, safe:</span></div><div style><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span style="font-size:13px"><div><br class="">jump</div><div><span style="white-space:pre-wrap"> </span>"Abandon thisContext and resume self instead (using the same current process)."</div><div><span style="white-space:pre-wrap"> </span>| process |<br></div></span><div style="font-size:13px"><span style="white-space:pre-wrap"> </span>process := Processor activeProcess.</div><div style="font-size:13px"><span style="white-space:pre-wrap"> </span>[process suspendedContext: self] forkAt: Processor activePriority + 1</div></div></div></div></blockquote>of course this fails at max priority. Since we don't use the max priority we can get away with this. I think that's more acceptable than getting away with occasionally popping the receiver off a context's stack, no? If that's not acceptable we need a primitive.</div><div style><br></div><div style><br></div></div></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><font color="#888888"><br><div>
<span style="border-collapse:separate;border-spacing:0px;font-family:'Lucida Grande';font-size:12px"><div style="word-wrap:break-word"><div style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert -</span></div><br></div></span><br>
</div>
<br></font></span></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>