Re: Dealing with "past" events

Don Y <blockedofcourse@foo.invalid> wrote:

Given:
N = "now"
R = task release time
D = task's deadline time
E = event time
 
The only real invariant is that R < N as code executing in a
task can't execute until the task has been released.
 
Specifically, there are no guaranteed relationship between
*most* of these times; N > E, N > D, D < R, etc. are all
possible in a generic system.
 
Though, in a nominal setting, R < N < E < D when the code tries
to initiate an event at a particular (future) time (E).
 
But, what happens when E < N -- i.e., when you try to schedule
an action (event) at a time that has already passed?  And, does
E << N lead to a different interpretation/handling?
 
I've argued that the OS shouldn't special-case such activities.
If you request something to happen in the past, then the OS
should just act as if it has *just* happened, regardless as to
whether you were a microsecond "late" in issuing your request
or *years*!  In particular, the OS shouldn't dismiss such request
unilaterally -- or, throw an error to alert the issuer to the
*apparent* inconsistency.

That is confusing formulation of the problem.  First, what is
"the OS"?  Second, your "task release time", "task's deadline time",
"event time" are undefined.  In particular, one meaning of
deadline is "time when a task should stop, regarless if it is
done or not".

If by "the OS" you mean operating system kernel, then you want
it as simple as possible and move various functions to upper
layers.  In particular, in general purpose OS you may have
timers which activate a task some time after scheduled time
(hopefully close to scheduled time, but there is no warranty).
Maybe you are thinking of such a timer.

However, there may be higher level "scheduler".  For example
Unix 'cron' and 'at' are userspace programs, but are considered
part of operating system. 'cron' and 'at' are rather crude,
if you may need more.  In particular, an automations system
typically must schedule various activities with specific time
constraints.

Anyway, your system probably is intended to do something useful
and that will lead to some requirements.  Once you have more
concerte requirements, you can think how to best satisfy them.
If you have only handful of time-dependent tasks and each
differs a lot from other, then putting all higher level
time handling in the tasks may be reasonable.  But usually
it pays to have common handling.  As George mentioned there
can be interdependencies between task, so it is likely that
you may need a higher level scheduler to coordinate them.
Concerning kernel, you should have in kernel enough to
support higher level code.  In particular, if you have
"fast" tasks and care about their time performance, then
you may need real-time features in the kernel.  If you do
not care, than usual general-purpose approach is enough.
But if you do not care, then why are you talking about
deadlines?

Concerning tasks way in the past: this is very unusual case
for general purpose kernel.  Namely, the only likely reason
for long delay is because system was turned off.  But kernel
timers frequently are "volatile", that is they will be gone
when system is turned on again (if that is undesirable, then
higher level layer may restore timers that were supposed to
persist).  AFAIK general purpose kernels handled timers
as you argue, that is dully activated corresponding task.
OTOH long delays were usually delegated to userspace which
could have complicated rules.

--
                              Waldek Hebisch