Hi Esteban,
On Fri, Mar 31, 2017 at 12:15 AM, Eliot Miranda <
[hidden email]> wrote:
>
> On Mar 30, 2017, at 2:58 AM, Pavel Krivanek <
[hidden email]>
> 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.
>
> 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.
>
> One other thing. I know "threaded heartbeat" is verbose, but I would really
> appreciate it if we could reserve "threaded vm" to mean a vm that
> multiplexes Smalltalk processes above native threads, even if not
> concurrently. This is the threaded ffi plan which we have a good chance of
> realizing this year.
It took me a while to realize that a contributing factor of the language
we see about this in pharo-dev is the file naming at
http://files.pharo.org/vm/pharo-spur32/linux/.
which seemed quite reasonable, but it light of Eliot's request,
perhaps the following naming would help distinguish
the "threaded heartbeat" from "threaded vm"
...-i386threadbeat-
...-i386timerbeat-...
btw, I dropped the "i" from the timerbeat vm since timer_settime() might
be a good alternative to setitimer() to avoid conflict with third-party alarm handling.
cheers -ben
(sorry to add another serving to your plate)