VM naming (was Re: [Pharo-dev] Iceberg with SSH on Linux)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

VM naming (was Re: [Pharo-dev] Iceberg with SSH on Linux)

Ben Coman
 
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)
Loading...