Re: Dealing with "past" events

On Mon, 4 Nov 2024 13:29:03 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

On 11/4/2024 10:36 AM, George Neuner wrote:

On Sun, 3 Nov 2024 16:53:14 -0700, 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?

 
There is no general answer to this: the only correct thing to do is
let the user specify how the event is to be treated if its scheduled
time is passed.

>
I argue that, if the developer expects such a condition to
occur *or* there is a significant consequence to allowing
it to be unconditionally scheduled when he would prefer it
NOT be, then he should condition his invocation of the
event instead of burdening the syscall with yet another
option:
>
     if !(now > event_time)
          schedule(event_time)
>
This also draws attention to the fact that the event should
NOT be scheduled in that particular case -- in a more obvious
way than some parameter to an embelished syscall.
>

It reasonably is safe to assume that a "do it now" event should be
executed as soon as possible, even if was delayed several seconds in
the scheduling.
 
But beyond that you're speculating.
   
Unix 'cron', 'at', etc. are not particularly good examples to follow -
they are too simplistic.  The set of options available to the Windows
scheduler is better (though not exhaustive), but IMO most of the
"options" should be mandatory parameters that must be provided in
order to schedule an event.

>
Those are exposed to users.  I'm looking at OS hooks that a developer
would exploit in an API (as above).

Not the point.  My comment was about what options / parameters are
available to the schedule(r).

This opens the possibility of another class of potential errors:
     schedule(event_time)
     ...
     schedule(event_time+delta)
     ...
what if now > event_time + delta?  If the developer had naively assumed
the first event would have completed within "delta" (instead of providing
a definite interlock on the scheduling of the second event), then you
could end up allowing both events to be "immediately" scheduled with
no clear indication of whether the first would complete before the
second got started.  (i.e., a race baked into the implementation)
>

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.

 
I think it should be an error for a /timed/ (not "now") event to be
scheduled past any possible execution time.  An event that repeats
could be scheduled past its initial run time, but there should be at
least one repetition in the /future/.

>
Run the speech recognizer's retraining algorithm at 01:00AM (because
no one is likely to be speaking, then).  Ah, but shit happened and
we couldn't get around to it until 1:30... should we abort that?

Now you're not paying attention: I suggested above to look at the
Windows scheduler.  One of the options (paraphrased) is "run asap if
missed".

But things like that should be the user / programmer choice based on
the task to be performed - not a system policy.

If you treat the tasks in a system as being flexible in their
scheduling (which is inherent in almost all multitasking systems...
you can't be assured when ANY task *actually* executes), then you
can't define hard limits as to how "late" something can happen.

Again the Windows scheduler: (paraphrased) there are options to
  "wait <time units> for idle state"        
  "wait until in idle state for <time units>"
  "stop if idle state ceases"  
  "start again if idle state resumes"
  "after trigger delay execution randomly for <time units>"
  "remove from schedule after <epoch>"
  "check for network connections available"
  "start only on line power"
  "stop if on battery"
  "wake up to run this task"
  "keep trying to start for so many <time units>"
  "stop/abort after so many <time units>"
  "stop the task if it runs too long"
  "force abort the task if it won't stop"

and more.

There are also /schedule/ priorities[*], and the task itself can be
scripted to run at a given OS priority (and as any particular user).
Sub "resource" for "idle" and this list ought to give you a few ideas
for what you should provide.


[*] schedule priority is not visible in the GUI. To see/modify it you
need to export the task to XML, edit the file and import it to
recreate the task with new settings.  Yeah, Windows really /is/ a pain
sometimes.

This is why I mentioned the "D"eadline in the times in my description.
I.e., if the task's deadline has passed, then does THAT impact
whether or not you should honor its request to schedule an activity?
Ans:  Yes.  If it is a hard deadline (which the developer specified!),
then the developer should know that it is possible for the task to
be aborted at any time prior to its completion.  if the scheduling
was important, it shoul dbe handled in the task's deadline handler
with some interaction with the mainline code (did this get scheduled
before the task abended?)
>

E.g., an event that repeats 5 times at 1 day intervals starting 7 days
ago is meaningless now.  But an event that repeats 5 times at 1 day
intervals starting /3/ days ago still has potential to execute.
 
Arguing that an administrator might (re)set the system time and that
might make a passed event relevant again is just wishful thinking.

>