Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32265

Re: Dealing with "past" events

Show key headers only | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-03 16:53 -0700
  Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-04 12:36 -0500
    Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-04 13:29 -0700
      Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-05 18:21 -0500
        Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-05 17:05 -0700
          Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-06 17:25 -0500
            Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-06 17:13 -0700
              Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-08 01:25 -0500
                Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-08 00:52 -0700
                Re: Dealing with "past" events George Neuner <gneuner2@comcast.net> - 2024-11-10 12:54 -0500
                Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-10 13:12 -0700
  Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-14 20:54 +0000
    Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-14 15:18 -0700
      Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-24 02:14 +0000
        Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-23 20:40 -0700
          Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-24 13:36 +0000
            Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-24 12:50 -0700
              Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-24 13:03 -0700
                Re: Dealing with "past" events antispam@fricas.org (Waldek Hebisch) - 2024-11-24 21:26 +0000
                Re: Dealing with "past" events Don Y <blockedofcourse@foo.invalid> - 2024-11-24 14:41 -0700

csiph-web