Hi Ben,

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

On Fri, Jan 6, 2017 at 10:44 PM, Guillermo Polito <guillermopolito@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