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: Wed, 6 Nov 2024 17:13:50 -0700
Organization: A noiseless patient Spider
Lines: 161
Message-ID: <vgh0o5$2at8o$1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 07 Nov 2024 01:13:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a640379ae92595b2114d623aacf27dcc";
	logging-data="2454808"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+qkhKq3beTzNd3+WxaP5Lc"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:R1O69IleeqioT+GIpL878jk1/7Q=
Content-Language: en-US
In-Reply-To: <ovonij51bqdce4kr9o4bvqr331i7b49746@4ax.com>
Bytes: 8672

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)

>>>> 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.
> 
> What you're describing here is meta: it's a condition of utilizing the
> scheduler in the 1st place, not a condition of triggering a scheduled
> event.

Exactly.  Why tell the scheduler how to respond to changes in the
environment -- changes that you can never completely anticipate
in designing an API.

Let the application figure out what "makes sense" for it.

If the time for the event/activity is passed and that is inconsequential
to the scheduling of that activity, then go ahead and unconditionally
schedule it.

If, however, there is some (possibly complex) relationship between
the CURRENT environment and the ANTICIPATED environment, let the
developer sort out the significance of these differences and
make a conscious decision as to how to proceed, if at all.

> I think what you may really /mean/ is dependency scheduling ... i.e.
> "this event depends on there being one or more other events already
> scheduled".

No, it is a reflection of how "now" has changed from what the
developer THOUGHT "now" would be like when that line of code
(schedule(x)) was about to be executed.

E.g., the event_time+delta clearly reflects an assumption that the
previous event -- at event_time -- will have completed before the
next event occurs.  Unless there is some other mechanism in place
to assure this, it is likely a faulty assumption.

So, write the code ignorant of that possibility and address the
bug WHEN it manifests.

OR, redesign the implementation so that implicit expectation
is made more explicit.  E.g., possibly require the first event
to set a flag to indicate that it HAS completed before you
allow the second event to proceed (even if both have been skewed
significantly in time).

> The number and criticality of such dependencies can be unbounded - or
> at least unworkable to specify - and I don't think checking for them
> belongs /in/ the scheduler or its API.  If some program depends on
> such meta knowledge of what is scheduled, it should have to keep track
> of that itself.

That is my point.  schedule(X) simply and unconditionally schedules X.
If the task abends BEFORE that line of code executes, then it is the
developer's job to figure out how <whatever> has been impacted by
that non-event.  E.g., if it NEEDS to be scheduled, regardless, then
redesign the application to make that guarantee explicit and obvious.

If the scheduled time PASSES before that line of code executes,
then, similarly, it is up to the developer to decide how it
should be handled.  E.g., if the activity only makes sense at
that particular point in time, then you don't want to schedule
it if that point in time is no longer attainable.

So, schedule() is freed from being concerned with these issues.

If you want an "agent" to implement some particular policy on your behalf,
then create one; spawn another task that enforces that policy in
explicit code (so a maintainer sees that this is an important
aspect of the algorithm)

>>> 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.
>>
>> And, no matter how many -- and how BLOATED the syscall becomes -- there
>> will STILL be conditions that are applicable to specific tasks.
>>
>> Rather than trying to anticipate ALL of them to handle *in* the
>> syscall (and STILL having to account for others that were not
>> envisioned), it seems more prudent to have the syscall UNCONDITIONALLY
>> perform its action and let the developer assume responsibility for
>> writing explicit code to handle cases that *it* considers as "special".
>> Especially as bugs *there* are readily contained in the task's
>> environment and don't risk corrupting the kernel.
> 
> If all the options can be (de)selected individually, then you don't
> have to bundle them all together ... but then you run the risk of the
> programmer forgetting something.
> 
> It's a good idea anyway for the API to allow modifying an existing
> schedule without having to delete/recreate it (even if "modify" really
> is just an illusion for the programmer).

It's just another object.  Anyone (including some OTHER task)
with an appropriate capability (set) can invoke whatever options
they deem necessary.  E.g., the deadline handler can use that
handle to delete the scheduled event if *it* determines that
it doesn't make sense to allow it to continue.

Of course, that only is possible if the event hasn't already been
triggered.

> Scheduling in a complex system is NOT SIMPLE and it never has been:
> whole books have been written about it.  The overwhelming majority of
> events likely will require only a small subset of the scheduler's
> options, but the scheduler itself must deal with the most complex case
> possible.

This is why it is easier (to get "right") a simple, unconditional
syscall that doesn't have to evaluate other conditions -- ASSUME the
caller had already done that work and DECIDED that the event should
be scheduled.  So, you ("I") can concentrate on JUST getting the event
scheduled.

> You might consider having multiple APIs [parameter blocks?] of varying
> complexity.  But there must be some version of the API that can
> specify every possible option.
> 
>>> 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.
>>