<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 4, 2016 at 3:01 PM, Denis Kudriashov <span dir="ltr"><<a href="mailto:dionisiydk@gmail.com" target="_blank">dionisiydk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><div class="gmail_extra">Hi</div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-04 9:38 GMT+02:00 Holger Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_-5664877562480419823:2tx" class="gmail-m_-5664877562480419823a3s gmail-m_-5664877562480419823aXjCH gmail-m_-5664877562480419823m1578ea0f954ce7da">Hey,<br>
<br>
so apparently I shot myself in the foot and created something like:<br>
<br>
[[] repeat] fork.</div></blockquote></div><div class="gmail_extra"><br></div>I tried it on latest Pharo on Mac. And no hang. Image continue working. UI start to be slower.</div></div></blockquote><div><br></div><div>In Squeak we have disabled processPreemptionYields to restore proper preemption semantics. That's why the above loop prevents the UI process from running.</div><div><br></div><div>Before, the VM always forced a process to yield if it was preempted, which made the scheduling non-deterministic. The time slice given to each process was random (whenever a higher-priority process became runnable). It did have the "advantage" of doing an implicit round-robin scheduling if multiple processes had the same priority. I guess that's what you're seeing in Pharo.</div><div><br></div><div>Cog supports both schemes via vmParameter 48.</div><div><br></div><div>- Bert - </div></div><br></div></div>