<div dir="ltr">Hi Esteban,<br><br>On Fri, Mar 31, 2017 at 12:15 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>><br>> On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <<a href="mailto:pavel.krivanek@gmail.com">pavel.krivanek@gmail.com</a>><br>> wrote:<br>><br>> Yes, the same priority. See:<br>><br>> The VM may have issues with clock jitter due to the heartbeat thread<br>> not running at elevated priority.<br>><br>><br>> It better /not/ be.  This is wrong.  The heartbeat thread /must/ run at a<br>> higher priority for the VM not to lock up when it becomes compute bound.  I<br>> thought the resolution was that the VM /will/ try and raise the priority if<br>> the heartbeat thread but will /not/ exit if it fails.  This is /very/<br>> different from not trying to raise the priority at all.<br>><br>> The resolution I thought we had reached means that if correctly installed<br>> the VM can work correctly, and will continue to work correctly if and when<br>> linux removes the annoyance of the conf files.  The resolution you describe<br>> Pavel (I hope inaccurately) means the threaded heartbeat VM will never work<br>> correctly.<br>><br>> One other thing.  I know "threaded heartbeat" is verbose, but I would really<br>> appreciate it if we could reserve "threaded vm" to mean a vm that<br>> multiplexes Smalltalk processes above native threads, even if not<br>> concurrently.  This is the threaded ffi plan which we have a good chance of<br>> realizing this year.<br><br>It took me a while to realize that a contributing factor of the language<br>we see about this in pharo-dev is the file naming at<br>    <a href="http://files.pharo.org/vm/pharo-spur32/linux/">http://files.pharo.org/vm/pharo-spur32/linux/</a>.<br>which seemed quite reasonable, but it light of Eliot's request, <br>perhaps the following naming would help distinguish <br>the "threaded heartbeat" from "threaded vm"<br>...-i386threadbeat-<br>...-i386timerbeat-...<br><br>btw, I dropped the "i" from the timerbeat vm since timer_settime() might <div>be a good alternative to setitimer() to avoid conflict with third-party alarm handling.</div><div><br>cheers -ben<br>(sorry to add another serving to your plate)</div></div>