Re: Dealing with "past" events

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.

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.

The problem with that is that it ends up putting a whole bunch of what
/effectively/ is - or should be - "scheduler code" into a whole bunch
of applications.  Instead of reducing application complexity by
introducing a smart service, you instead increase complexity by
forcing the application to figure out for itself when and how it can
make use of a dumb service.

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.

Where do you get that from ?

You wrote:

      schedule(event_time)
      ...
      schedule(event_time+delta)

All you can reasonably conclude from this fragment is that the
scheduler was invoked twice: first on the 1st event, then on the 2nd -
and that assuming they were scheduled successfully, the 2nd event can
be expected to be triggered at least "delta" time units after the 1st
is triggered.

Nothing in this indicates that "delta" is intended to allow the 1st
event to complete whatever it was supposed to do.  In fact, nothing
indicates the two events even are related.


Which is precisely the point I was making about scheduling options.
You have to have at least some way to deal with the relationship.  If
the 2nd depends on the 1st, then the tasks must signal outside the
scheduler, and the 2nd potentially must fail with a code the scheduler
understands means to "try again".  And then there must be options to
say how long before trying again, how many times to try again before
giving up, etc.     

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

You're assuming a particular style of coding ... I don't think you can
make that assumption.

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

Again, that is outside the pervue of the scheduler.  If A wants
somehow to signal B that it has completed, that has to be handled by
the tasks themselves.

Unless the scheduler can know that A has completed, and know the
status of A when it finished ... and make executing B dependent on
that.  But that is asking too much because:

I wrote previously -

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've already made up your mind that that is the way it must work,
then what the heck is this conversation about?

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.