On 31 March 2017 at 10:14, Alistair Grant <akgrant0710@gmail.com> wrote:
> Hi Eliot,
>
> On 31 March 2017 at 05:31, Eliot Miranda <eliot.miranda@gmail.com> wrote:
>>
>>
>> On Thu, Mar 30, 2017 at 8:20 PM, Eliot Miranda <eliot.miranda@gmail.com>
>> wrote:
>>>
>>> Hi Alistair,
>>>
>>> On Thu, Mar 30, 2017 at 9:32 AM, Alistair Grant <akgrant0710@gmail.com>
>>> wrote:
>>>>
>>>> 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/32f321583c69ca27e61ffaff6decc2a3e4b6ca5e
>>>>
>>>> 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)?
>>>
>>>
>>> The issue is that delays are recognized by periodically checking the time
>>> against the next delay expiry.�� It is the heartbeat thread that causes JITed
>>> Smalltalk code to break out of its execution to check for events, including
>>> the next delay expiry.�� So if the heartbeat is at the same priority as the
>>> JITed Smalltalk code, and the Smalltalk code is in tight enough a loop (one
>>> that does not provoke a GC, does not do any process switches) the heartbeat
>>> thread will not run and the delay expiry will never be tested for.
>>
>>
>> Something like the following should run forever if the heartbeat has the
>> same priority as the VM thread (and should be tried in a headless
>> configuration too):
>>
>> [| infiniteLoop |
>> infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum + (sum
>> even ifTrue: [1] ifFalse: [-1])]] newProcess.
>> infiniteLoop resume.
>> Processor activeProcess priority: Processor activePriority + 1.
>> (Delay forSeconds: 1) wait.
>> infiniteLoop terminate.
>> Processor activeProcess priority: Processor activePriority - 1] timeToRun
>> 1001
>
> I get the same result regardless of thread priority, UI or headless.
> I've just shown the output from the headless VM with the heartbeat
> thread at normal priority (I haven't incorporated Ben's comments in to
> the text yet):
>
>
> $ pharo Pharo.image --quit ~/pharo6/pharo/heartbeatTest.st
> pthread_setschedparam failed: Operation not permitted
> This VM uses a separate heartbeat thread to update the internal clock.
> For best operation, this thread should run at real-time priority,
> however the VM was unable to change the priority.�� The effect is that
> the clock may experience some jitter.�� To avoid clock jitter, please
> create the appropriate configuration file in /etc/security/limits.d
> by executing the following:
>
> cat <<END | sudo tee /etc/security/limits.d/pharo.conf
> *�� �� �� ��hard�� �� rtprio�� 2
> *�� �� �� ��soft�� �� rtprio�� 2
> END
>
> You will need to log out and log back in for the limits to take effect.
> For more information please see
> https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux
> Time to run: 0:00:00:01
>
>
> heartbeatTest.st:
>
> | time |
>
> time := [| infiniteLoop |
> infiniteLoop := [| sum | sum := 0. [sum < 10] whileTrue: [sum := sum +
> (sum even ifTrue: [1] ifFalse: [-1])]] newProcess.
> infiniteLoop resume.
> Processor activeProcess priority: Processor activePriority + 1.
> (Delay forSeconds: 1) wait.
> infiniteLoop terminate.
> Processor activeProcess priority: Processor activePriority - 1] timeToRun.
> FileStream stdout
> nextPutAll: 'Time to run: ';
> nextPutAll: time printString; cr.
> time

P.S It would be great is someone could reproduce this.�� Eliot and Ben's
descriptions make sense, so I can't help feeling I've done something
stupid here.