<br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 9:53 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><div><div>On 13.04.2010, at 18:46, Eliot Miranda wrote:</div><blockquote type="cite"><br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 9:24 AM, Randal L. Schwartz <span dir="ltr"><<a href="mailto:merlyn@stonehenge.com" target="_blank">merlyn@stonehenge.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>>>> "Ang" == Ang BeePeng <<a href="mailto:beepeng86@yahoo.com" target="_blank">beepeng86@yahoo.com</a>> writes:<br>
<br>
Ang> Are Squeak processes pre-emptive? Are infinite loop processes safe<br>
Ang> to run?<br>
<br>
Squeak uses a simple priority scheme.<br>
<br>
A Squeak process runs until it yields or it is interrupted by a higher<br>
priority process event. When it is interrupted, it goes to the back of<br>
the queue, so when the higher priority process pauses or completes,<br>
other processes at the same priority are likely to be run instead.<br></blockquote><div><br></div><div>IMO the sending of the preempted process to the back of the queue is a bug. It means one cannot rely on cooperative scheduling within a priority level. On the other hand, if the VM does not send the preempted process to the back of the queue there is nothing to prevent a higher-priority process altering the run queues of lower priority processes, achieving the same thing. But it is flexible if the scheduler code does it rather than the VM. One can imagine per-process priorities being examined so that by default a process gets moved to the back of its run queue when preempted, but if a process has a "don't preempt me" property it is not.</div>
</div></blockquote></div><div><br></div></div><div>My guess is this odd behavior was like an accidental round-robin scheduler ... But changing it now might provoke rather obscure problems, no?</div></div></blockquote><div>
<br></div><div>That's certainly possible, but not the VisualWorks experience. One can simply add a yield to allow other processes at the same priority level to run. If there aren't any high-priroity processes running sporadically then one needs yields anyway. So it is highly likely that in cases where the programmer wants to yield they have explicitly used a yield. I think it much more likely that the current behaviour creates obscure problems because sometimes implicit yields occur and at other times they don't, depending on the state of finalization, whether delays are in progress or not, etc.</div>
<div><br></div><div>But I agree it seems like a big change. I just think it's a change for the better :)</div><div><br></div><div>best</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;">
<div style="word-wrap:break-word"><br><font color="#888888"><div>
<span style="border-collapse:separate;border-spacing:0px 0px;color:rgb(0, 0, 0);font-family:Lucida Grande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-family:Helvetica">
<span style="font-family:Helvetica">- Bert -</span></div><br></span>
</div>
<br></font></div><br><br>
<br></blockquote></div><br>