[Vm-dev] Unix heartbeat thread vs itimer

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 12 01:18:55 UTC 2017


Hi Ben,

On Sat, Apr 8, 2017 at 6:39 PM, Ben Coman <btc at openinworld.com> wrote:

>
>
>
> On Fri, Jan 6, 2017 at 10:44 PM, Guillermo Polito <
> guillermopolito at gmail.com> wrote:
>
>>
>> Hi,
>>
>> I was checking the code in sqUnixHeartbeat.c to see how the heartbeat
>> thread/itimer worked. It somehow bothers me that there are different
>> compiled artifacts, one per option.
>>
>> What do you think about having a VM that manages that as an argument
>> provided when we launch the VM? This would add some flexibility that we
>> don't have right now because we make the decision at compile time.
>>
>>
> Can someone advise how to create a new VM setting and read/write to it
> from the Image?
>

Give me an example of the kind of setting and I'll make you through it.
The kinds of settings I know about are:

1. has a command line keyword and argument to set it

2. has a persistent value stored in the image header and is set via
vmParameterAt:[put:]

3. 1 + 2

As a challenge, I'd actually like to play with dynamically switching the
> heatbeat between threaded & timer while the Image is running.
>
> Also it would be nice for the Image to be able to inspect what priorities
> the heatbeat thread is running at.
>

Ugh :-(  That's a lot of plumbing.  Much easier to just put a printf in a
custom version of the VM somewhere?


As well, what is the simplest reliably crashing example of signal conflict
> with the timer-beat VM?
>

There isn't a way that reliably crashes the Vm (it doesn't crash).  Instead
I posted an example which should demonstrate the problem.  Here it is again.

[| 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

Remember to test it on an older kernel which doesn't have the improved
schedulers to confirm that the example locks up.


>
> cheers -ben
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170411/4537ea81/attachment.html>


More information about the Vm-dev mailing list