Re: Dealing with "past" events

On Fri, 8 Nov 2024 00:52:28 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

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*?

Say you want a task to start every day at 00, 08 and 16.  You don't
care that it starts exactly on time, but you don't want the ideal
start time to drift with execution, so (re)scheduling as part of the
task won't do.

Say you want a task that runs M,W,F at 10, and T,Th,Sa at 14. Sunday
it does not run.  Again, you don't care that it runs exactly on time,
but it must complete within an hour and so it must start within 15
minutes of the scheduled time or it can't be run.


Are you going to run a scheduling task every day to schedule for
tomorrow?  What if that task doesn't get run?

Are you going to run one or more monitor tasks constantly (wasting CPU
and power) to schedule other tasks? 

IMO either of these are ridiculous.


You want a schedule that starts at 00, repeats every 8 hours, and
(pending resources) continues to try to start for X <time>.

You want a schedule that runs M,W,F at 10, tries to start for up to 15
minutes, then aborts if it can't be started.  You want a second
instance of this schedule that runs T,Th,Sa at 14.

And you want options in your /scheduler/ to be able to specify these
conditions.

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.