On Fri, Mar 31, 2017 at 12:15 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

_,,,^..^,,,_ (phone)

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.

"may" is fairly broad term and presumptive at this stage. ��

While the *static* priority of the heartbeat and interpreter threads is the same,

the heartbeat-thread mostly sleeps, so its *dynamic* priority will be higher than the interpreter thread.

This is even more so when the interpreter-thread is compute intensive.��

This behaviour is (maybe) Linux specific, but its only Linux that has a problem raising the heartbeat-thread priority.��

So the threaded-heartbeat "should not" have more jitter than before,

but I'm still meaning to confirm this by experiment with a minimal C-lang thread��code example.

However I speculate that in a heavily loaded system, the itimer-heartbeat may have *slightly* better jitter��

than even a high-priority-heartbeat-thread, since IIUC signal handling preempts even higher priority threads.

But most modern systems operate <20% CPU.�� Specific experiments would be needed to comment further,

but I'd hazard to guess the itimer-heartbeat might only be an advantage for audio on heavily loaded systems.

Not your common Pharo system. In balance against itimer conflicts with OSProcess and third-party C libraries,

the threaded-heartbeat seems preferable (if all the above remains true in practice).�� Although I'm reading��

some stuff that may also resolve the timer-heartbeat issues.

cheers -ben

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.

Good point.�� We can make use of our good friend hyphen... threaded-heatbeat & heartbeat-thread.

cheers -ben

��

An exit may be appropriate in some
cases, but for most users the above warning is sufficient.

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/32f321583c69ca27e61ffaff6decc2a3e4b6ca5e

Cheers,
-- Pavel

2017-03-30 11:51 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:

2017-03-29 20:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi,

I want to let you know that the SSH (git@...) support in Iceberg on Linux VM now works with the latest threaded VM (get.pharo.org/vmTLatest60). The threaded VM now runs without root priviledges nor special configuration of the system.��

And what the logic now? Heartbeat and VM are in same priory?