Now we find that Kernel needs an alarm syscall: this comes about by contemplating animations and our stomachs. Regulated meals can be all the religion we need, which we do by choosing an appropriate unit of time, inverting it to create a unit of frequency, and then multiplying this by the number of meals.
Religion can become obsession, we know. Those who think this is a disorder to be treated, might want to wind back some eight hundred years and contemplate a blossoming woman in shining white, who some might say sits in Heaven. But others seem not so sure. Choosing a measurement of time is as interesting to us as choosing a measurement of length: we might expand our unit so as to reach back to the last civilization that lost all of its knowledge. And we might make this the period. This will at least stop us once and for all contemplating personal suffering.
For the numerator we place the number of artists who received recognition in their lifetime. This is not a metaphor: it is to demonstrate an obvious fact.
It is as much within my power to insist an artist be recognized as it is to insist a signal is received on time.
It is also to hopefully give some guidance to those who treat obvious facts as laughing matters: a jiffy is a unit of time that is a limitation that must be built in to a Kernel, and determined by it.
We now have some things to name. Each process requires the addition of the system jiffy by which its actual animation rate is measured, which will simply be called last, as well as what aught to be obvious, ticks and jiffies_per_tick.
It may so be that jiffies are subdivisable, in which case we might have ticks_per_jiffy as well, used in exclusion to the inverse and in combination with a form of probabilistic scheduling, but at present we're not trying to replace cogs and gears.
The animation parameters, as now identified, will be used in each Kernel iteration to determine both the whether a proc is due for animation, and to determine the number of jiffies until the next or following required tick (animation_required).
tick_required = ticks * jiffies_per_tick <= (system - last);
If a tick is required, we calculate the interval by forming
a variable for the next value of ticks, which we needn't identify
because we simply refer to
next = last + ( ticks + tick_required ) * jiffies_per_tick;
In our present toykernel implementation, when a proc does get processor time all procs are rechecked, so that only next values in which a tick is not required are relevant.
Note that state one is equivalent to setting jiffies_per_tick to nought, so that we might define that a proc is being animated when it has non-zero ticks. At present, however, we assume that when jiffies_per_tick is nought no animation is taking place.
More importantly we would need to take care of overflow, both of the system jiffy and the number of ticks. This would be a matter of updating the values of last when appropriate, as well as rounding the number of ticks when this reaches overflow. But, I gather, this has all been taken care of by others whose kernels are now being used in just about everything.
And I'm just wasting energy by looking at animations of not much in particular. It's certainly a lot more pleasant than looking at a garden that is threatening to become overgrown, or thinking about what an overgrown person is going to do in the medium term.
Oh well, short term goals then: git commit; git push.