Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: comp.arch.embedded
Subject: Re: Dealing with "past" events
Date: Sun, 10 Nov 2024 13:12:20 -0700
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <vgr435$hiug$2@dont-email.me>
References: <vg92dc$ja6r$1@dont-email.me>
 <fdqhij1nv99fb05c3qkm6rammvd6d6n0tc@4ax.com> <vgbaqi$13mac$1@dont-email.me>
 <rj8lijhlg0s4aloifg0ac17f1ckunm2174@4ax.com> <vgebs8$1otfe$1@dont-email.me>
 <ovonij51bqdce4kr9o4bvqr331i7b49746@4ax.com> <vgh0o5$2at8o$1@dont-email.me>
 <3m7rijttrdnme4qoim7tiqgpm1pm3553qc@4ax.com> <vgkg04$342nj$1@dont-email.me>
 <ieq1jjhkf5mi1oggp58tvtclckdindldt7@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 10 Nov 2024 21:12:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1ebadedf5f486e5a614307a677d4842b";
	logging-data="576464"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX192JeKolqwtu9mhE3Qfz0v8"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:uyKvYXV9S7yo7tbXjmNQud9Tcps=
In-Reply-To: <ieq1jjhkf5mi1oggp58tvtclckdindldt7@4ax.com>
Content-Language: en-US
Bytes: 7088

On 11/10/2024 10:54 AM, George Neuner wrote:
> 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.

You schedule *one* task that schedules the "real" task, based
on it's dynamic observations of the current state of the system.

If the Monday task couldn't run at 10 -- because of a power outage -- should
it be rescheduled to run when power resumes?  Should it be ignored because
the Tuesday task will effectively address the issues that were NOT
addressed by the Monday (non)invocation?

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

Exactly.  See above.

What if the *scheduler* doesn't run?  Do ALL tasks in the system that
it was responsible for initiating stop running?

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

A task that idles consumes few resources.  Is the "scheduler"
wasteful of CPU and power?

> 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.

No.  That complicates the scheduler to handle *arbitrarily* complex cases
("schedule this if it has NOT rained", "schedule this if there have
been visitors", "schedule this if there has been a power outage",
"schedule this if the database needs to be vacuumed", etc.).

Let the "parent" of the task sort out when it should run and
write explicit code to test for those conditions.  If that
code is buggy, then *it's* scheduling is buggy -- but not the
scheduler itself.

>> 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.

Do note that the question *posed* was:
    how to handle a scheduled event time when said time was
    in the recent -- or distant -- past.