Hi Eliot, On 30 March 2017 at 18:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Yes, the same priority. See:
The VM may have issues with clock jitter due to the heartbeat thread not running at elevated priority.
It better /not/ be. This is wrong. The heartbeat thread /must/ run at a higher priority for the VM not to lock up when it becomes compute bound. I thought the resolution was that the VM /will/ try and raise the priority if the heartbeat thread but will /not/ exit if it fails. This is /very/ different from not trying to raise the priority at all.
As Esteban wrote, the vm is trying to raise the priority. You can see the change at: https://github.com/pharo-project/pharo-vm/commit/32f321583c69ca27e61ffaff6de... I'd like to just make sure I understand your comment correctly: Are you saying that the VM will lock up if it gets in to, e.g., an endless loop, so that Ctrl-. fails to interrupt. Or is it more serious than that? Can the VM become locked up for just a long running process (I guess it will be locked while the process is running, but will eventually go back to normal once the process completes)? Also, a change was made to the travis test setup in: https://github.com/pharo-project/pharo-vm/commit/5418a415e9297f601f6d57ee732... The comment is: "No need to raise rtprio limit anymore"
From your comments above, this doesn't seem accurate.
I'm in the middle of adding some details to the text that is printed out by the threaded heartbeat vm, and from what you're saying, maybe we should add some more warnings.
The resolution I thought we had reached means that if correctly installed the VM can work correctly, and will continue to work correctly if and when linux removes the annoyance of the conf files. The resolution you describe Pavel (I hope inaccurately) means the threaded heartbeat VM will never work correctly.
Thanks, Alistair