Re: Dealing with "past" events

On 11/7/2024 11:25 PM, George Neuner wrote:

On Wed, 6 Nov 2024 17:13:50 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:
 

On 11/6/2024 3:25 PM, George Neuner wrote:

You asked how best to handle these things.  The answer is provide
options in the scheduler and ensure that the options are (at least)
considered by the programmer by making them /required/ parameters.
>
If you don't like the number of parameters, pass them as a structure.

>
I object to the *complexity* that all those different potential
conditionals impose on the facility.
>
If you want a fancy/smart scheduler interface, build a *service*
that implements it and let *that* talk to the actual scheduler.
If the service fails, then any clients that RELY on it get screwed,
but the REAL scheduler still keeps working (for ITS clients)

 The problem is that the REAL scheduler /needs/ the flexibility of all
of those options to do its job.  You can put lipstick on the pig - ie.
use a service to present a more friendly use API - but that doesn't
change the underlying requirements.

No, it doesn't.  The scheduler just has to make a task ready for
execution NO SOONER THAN a particular time.
E.g., if you write:
     delay(1000)
all you know is an interval OF AT LEAST 1000 will occur before
the next statement executes.  It may be longer -- if there are
competing needs -- but likely won't be EXACTLY 1000.
Guaranteeing a particular time is impossible -- because you don't
know *if* the request will be made prior to that time (or not)
and how much "other work" will compete for the processor.
If guaranteeing the time for one event is impossible, then how
is it possible to guarantee the time for a *subsequent* event
(envisioned when the code was *written*, not executed).
If you want a particular (set of) condition(s) to apply to the
task's execution, then STATE them.  Delegating those things to some
other service/facility constrains what you can do with that
facility.  So, in some places, you rely on it and in others
you augment it.
If it can't handle EVERY condition, why burden it with handling *any*?
I've gone through each of the "special cases" that have been presented
to me and shown how to get the behavior ACTUALLY sought by conditioning
such invocations.  Keeping the scheduler simple (so it can concentrate
on getting all of the *resources* that a task will need "on line"
so the task *can* be dispatched) eliminates complexity that often
would not address real needs (but will allow opportunities for
faults to manifest in the code).
It also makes it easier to track the actual resources used by
a task (that is scheduling) because you can watch while *it*
is executing -- instead of having to figure out how much of the
scheduler's activities (at a possible later time) are "chargeable"
to that task.