Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32261

Re: Dealing with "past" events

Show all headers | View raw

On Tue, 5 Nov 2024 17:05:23 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 11/5/2024 4:21 PM, George Neuner wrote:
>
>>>> It reasonably is safe to assume that a "do it now" event should be
>>>> executed as soon as possible, even if was delayed several seconds in
>>>> the scheduling.
>>>>
>>>> But beyond that you're speculating.
>>>>      
>>>> Unix 'cron', 'at', etc. are not particularly good examples to follow -
>>>> they are too simplistic.  The set of options available to the Windows
>>>> scheduler is better (though not exhaustive), but IMO most of the
>>>> "options" should be mandatory parameters that must be provided in
>>>> order to schedule an event.
>>>
>>> Those are exposed to users.  I'm looking at OS hooks that a developer
>>> would exploit in an API (as above).
>> 
>> Not the point.  My comment was about what options / parameters are
>> available to the schedule(r).
>> 
>> 
>>> This opens the possibility of another class of potential errors:
>>>       schedule(event_time)
>>>       ...
>>>       schedule(event_time+delta)
>>>       ...
>>> what if now > event_time + delta?  If the developer had naively assumed
>>> the first event would have completed within "delta" (instead of providing
>>> a definite interlock on the scheduling of the second event), then you
>>> could end up allowing both events to be "immediately" scheduled with
>>> no clear indication of whether the first would complete before the
>>> second got started.  (i.e., a race baked into the implementation)
>>>
>>>>> I've argued that the OS shouldn't special-case such activities.
>>>>> If you request something to happen in the past, then the OS
>>>>> should just act as if it has *just* happened, regardless as to
>>>>> whether you were a microsecond "late" in issuing your request
>>>>> or *years*!  In particular, the OS shouldn't dismiss such request
>>>>> unilaterally -- or, throw an error to alert the issuer to the
>>>>> *apparent* inconsistency.
>>>>
>>>> I think it should be an error for a /timed/ (not "now") event to be
>>>> scheduled past any possible execution time.  An event that repeats
>>>> could be scheduled past its initial run time, but there should be at
>>>> least one repetition in the /future/.
>>>
>>> Run the speech recognizer's retraining algorithm at 01:00AM (because
>>> no one is likely to be speaking, then).  Ah, but shit happened and
>>> we couldn't get around to it until 1:30... should we abort that?
>> 
>> Now you're not paying attention: I suggested above to look at the
>> Windows scheduler.  One of the options (paraphrased) is "run asap if
>> missed".
>> 
>> But things like that should be the user / programmer choice based on
>> the task to be performed - not a system policy.
>
>This goes beyond "system policy" (which would be some default
>way to handle these types of incidents)
>
>Did you miss:

No I did /not/ miss this. 

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 argue that, if the developer expects such a condition to
> >> occur *or* there is a significant consequence to allowing
> >> it to be unconditionally scheduled when he would prefer it
> >> NOT be, then he should condition his invocation of the
> >> event instead of burdening the syscall with yet another
> >> option:
> >>
> >>       if !(now > event_time)
> >>            schedule(event_time)
> >>
> >> This also draws attention to the fact that the event should
> >> NOT be scheduled in that particular case -- in a more obvious
> >> way than some parameter to an embelished syscall.
>
>The variety of different conditions that could be practical
>would needlessly complicate a syscall.  E.g., to handle:
>
> >>       schedule(event_time)
> >>       ...
> >>       schedule(event_time+delta)
> >>       ...
>
>one might condition the *second* schedule() with:
>
>         if (first_scheduled)
>             schedule(event_time+delta)
>
>>> 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.

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

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.

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


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.

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

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