VM naming (was Re: [Pharo-dev] Iceberg with SSH on Linux)
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)