<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 2, 2017 at 3:11 AM, Petr Fischer <span dir="ltr"><<a href="mailto:petr.fischer@me.com" target="_blank">petr.fischer@me.com</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 class="gmail-HOEnZb"><div class="gmail-h5"><br>
> On Thu, 30 Mar 2017, Eliot Miranda wrote:<br>
><br>
> > Once the active process is in a tight loop the delay is effectively<br>
> disabled because the tight loop effectively shuts out the heartbeat thread<br>
> and hence the system never notices that the delay has expired.<br>
><br>
> I think that won't happen, because the process scheduler (O(1), CFS, BFS) on<br>
> linux is not cooperative. So, the kernel will periodically preempt the main<br>
> thread and run the heartbeat thread no matter what their priorities are. The<br>
> higher priority only provides lower jitter on the heartbeat thread.<br>
><br>
> Levente<br>
<br>
</div></div>Is there some test case or code, that I can run in Pharo and evaluate if kernel sheduler is working correctly (with heartbeat thread at normal priority).<br>
I need to test it under FreeBSD.<br>
<br>
Thanks! pf<br></blockquote><div><br></div><div>Just for starters, what result do you get for my multi-priority fibonacci stress test... </div><div><a href="http://forum.world.st/Unix-heartbeat-thread-vs-itimer-tp4928943p4938456.html">http://forum.world.st/Unix-heartbeat-thread-vs-itimer-tp4928943p4938456.html</a> </div><div><br></div><div>cheers -ben</div></div><br></div></div>