Re: Dealing with "past" events

On 11/23/2024 7:14 PM, Waldek Hebisch wrote:

Don Y <blockedofcourse@foo.invalid> wrote:

That is confusing formulation of the problem.  First, what is
"the OS"?

>
Doesn't matter.  The question is about how one should EXPECT an OS
to handle such things.

 It matters.  OS kernel should implement something simple, but enough
to support higher layers.  At higher layers you may have something
more fancy.

You asked:  "What OS?"  The OS doesn't matter.  Rather, how
the mechanism is modeled.
As you've said, the OS "should implement something simple".
Something easily conceptualized, even if it doesn't address
all possible use cases.
If, for example, the OS assumes that "past" events are no longer of
interest and ignores the request, then any higher layers have to
take that into account to COMPENSATE for the POLICY decision that
the OS has enforced.

If by "the OS" you mean operating system kernel, then you want
it as simple as possible and move various functions to upper
layers.  In particular, in general purpose OS you may have
timers which activate a task some time after scheduled time
(hopefully close to scheduled time, but there is no warranty).
Maybe you are thinking of such a timer.

>
I am thinking one layer above that, in terms of abstraction.
Imagine some concurrent agency "watching the clock" and
taking action on your request to make something happen at a
particular time.  *YOU* may be busy with something else.

 I take this and what you write later that you think about
library interface for "applications".

A library function or a *service*.

However, there may be higher level "scheduler".  For example
Unix 'cron' and 'at' are userspace programs, but are considered
part of operating system. 'cron' and 'at' are rather crude,
if you may need more.  In particular, an automations system
typically must schedule various activities with specific time
constraints.
>
Anyway, your system probably is intended to do something useful
and that will lead to some requirements.  Once you have more
concerte requirements, you can think how to best satisfy them.
If you have only handful of time-dependent tasks and each
differs a lot from other, then putting all higher level
time handling in the tasks may be reasonable.  But usually
it pays to have common handling.  As George mentioned there
can be interdependencies between task, so it is likely that
you may need a higher level scheduler to coordinate them.

>
My contention is that said service can't possibly know of all
of the interdependencies that could exist (examples provided
in other posts).  So, let the service focus on a single criteria:
the time at which you desire the action to occur.

 You can not solve _all_ scheduling problems.  It does not

Correct.

mean that you should not solve some.  Windows style interface

You should only solve those that are commonplace -- and, only
as a convenience for your clients.
If nothing is common (unlike windows where applications may want
to know if the host is running on batteries, just came out of
hibernation, etc), then anything additional that you do in
the kernel just adds to the kernel's complexity without any
real reward.

where you have a lot of specific cases and can not do anything
else than provided choices does not look attractive to me.
OTOH 'constraint language' to specify various constraints
(which may be combined in arbitrary ways) could go quite
far.  There is also time-honored approach of allowing "user"
extentions (possibly up to replacing "standard" scheduler).

The "constraints" would then have to be available/accessible
to the scheduler.  This leads to monolithic designs -- the scheduler
has to be able to know ANYTHING that may be of importance.
Instead, it should only have to know what is ESSENTIAL for it to perform
its action.
"Schedule this at 1:00AM but only if it did not rain, today"
Why should the scheduler have to know about local precipitation?
Instead, the task that thought that was a significant criteria
likely already knows about it; why not let *it* condition the
scheduler's actions?

Consider, however, that the service may be displaced by some higher
priority tasks executing on its hardware.  So, it can't guarantee
that it ever *sees* the specific time you've specified; other
tasks may have preempted it.  So, expecting to hit a specific
time is wishful thinking.

 Again, this is question of design of your OS and your requirements.
If you have badly behaving third party code, then it may be hard to
give any warranty.

The code doesn't even have to be malicious.  I'm sure everyone
has had their workstation grind to a halt because something is
working as designed, but the set of applications aren't working
as EXPECTED.
(E.g., my browser routinely seems to run out of memory... or sockets...
or <whatever> meaning I can't open another page until I close it
and reopen it.  Even if all the same tabs are reopened with it!)

But if you have need and apropriate resurces
then there are ways to get real-time behaviour (that is hitting
specified time window).  Even if you do not have real-time
motivation, I think that time windows (as opposed to discrete
events) appear frequently.  For example, you want to turn on
a device during night tariff.

Yes.  Or, the developer may have "noticed" (or expected)
certain behaviors that it can exploit.  E.g., at this time,
the system load is low so it would be a good use of resources
(without incurring conflicts) for me to perform this resource
intensive task.

Anyway, if you can not give reasonable warranties for time
when your scheduler runs, then it means that you do not care.

No.  It means you care MORE about other things.
E.g., if power fails, I start shedding computational
loads so I can power down processors.  The first to
go are those that are "unessential" or that can easily
be restarted to resume their state.
As I don't know how long a power outage will last
(but I *do* know how long my backup supply will support
a particular load set), I can't guarantee that "your"
task will be running anywhere when its deadline or
event times come to pass.
Similarly, if some high priority task manages to continually
preempt you, then you can't predict when you will next
"run" on the processor.
You've been preempted because your stated timing requirements
have been deemed insufficient to compete for the CURRENT
set of resources, given the other candidates vying for them.
The consequences of you not running may be serious.  Or,
insignificant.  Only YOU can determine that.
If, instead, you make a proclamation to the system
regarding your "importance"/timeliness, then it's easy
for foreign code to abuse that mechanism and always
claim to be "very important" and with "immediate"
timing criteria.
[To counter such abuse, if the workload manager sees
that it can't meet your requirements, it simply refuses
to run your application:  "Why bother?  You've already
CLAIMED to have these requirements and I *know* that
I can't meet them, so why forfeit resources trying to
meet your goals -- at the expense of other tasks -- only
to KNOW it will fail?"]

By extention, you do not care when scheduled tasks run.
Which may be fine for some purposes and in such case simplistic
handling which you propose may be good enough.
 When you wrote your original post, I had someting different in
mind.  Not so long ago I looked at one of home automation
system.  I searched for some specific info and one of first
things that I found was a discussion about scheduling interface
in the system.  A user wanted simply looking thing "if washing
machine is idle for some specified time, then turn its power off".
System allowed specifying conditions which caused some actions.
But there were limitations on what could be put as a condition,
and in effect correctly specifingt needed thing was rather
awkward.

Exactly.  Baking that into the OS is wrong.  It should
implement MECHANISMS (i.e., the ability to load an application
into memory and ensure it's required resources are available)
and not POLICY (the criteria that an application may deem important)

  But kernel
timers frequently are "volatile", that is they will be gone
when system is turned on again (if that is undesirable, then
higher level layer may restore timers that were supposed to
persist).  AFAIK general purpose kernels handled timers
as you argue, that is dully activated corresponding task.
OTOH long delays were usually delegated to userspace which
could have complicated rules.

>
You have to assume these are unprivileged (out-of-kernel)
tasks -- because you don't want to bring more code *into*
the kernel.

 Out-of-kernel does not mean unprivileged.

In *one* sense of the term.  A service can operate at an
elevated sense of "importance" and timeliness.  But, it
should be an appendage and not be able to interfere
with the operation of the kernel.
E.g., if a scheduler service dies, then NEW tasks can't
be invoked at specific times.  But, tasks that are
already running -- or, explicitly loaded by them -- are
not affected.  The 'damage" is contained.
One can then implement a "Lazarus service" that watches for
key services crashing and restarts them.  E.g., there are
times when the display driver on my main workstation
crashes (usually coming out of hibernation or some other
significant hardware change).  But, that is detected and
it is restarted so I am only momentarily inconvenienced.

 Tasks may have
special rights which other tasks do not have.  For example
one may allow elevated scheduling priority only to system
tasks.  Even otherwise unprivileged task may be special
because it provides "well-known" interface to other tasks.

Exactly.  Everything in my world is capability based.
E.g., you can't even USE the scheduler if you haven't been
given a capability to do so.
"Why should the 'Flashlight' app in your phone be able to start
other tasks???"

So, I argue that a simple criteria be adopted and the writer of
the task requesting the scheduling (and the task being scheduled)
address their own specific criteria IN EXPLICIT CODE to enforce
these, instead of hoping some other service can be made aware of
these requirements (by embelishing that service?  by including
support fr up-calls to the task doing the scheduling??)
>
The "scheduler" can then just focus on ensuring each event gets
processed exactly once and at a time NO EARLIER than the time
specified.  This is much easier for a developer to wrap his head
around than trying to second-guess the scheduler ("What if the
scheduler is blocked for some period of time?  How will *it*
handle things when NOW is later than it *could* have been -- or,
when there are MANY competing things in the queue?")

 For me important question is "who is the master?".  Do you allow
third-party code to play any tricks it wants.

The app has to declare what it wasn't to be able to access
before it is installed in the system.  If it attempts to
ask for some capabilities that it shouldn't need, then the
installer can refuse to allow the code to be installed.
If it misbehaves while running (abuses some capability
that it has been granted), the system can refuse to allow
it to be restarted.

Or do you give
control to the user.  As a simple example, task may decide to
do some work at night, presumably to avoid interference with
user work.  But a user may prefer to work at night, say on a
specific day.  So user may wish to delay execution of the task.
If you want to empower users, then central facility is
proferable, as this is easier to control than separate tasks.

Users can schedule some activities/actions through a "user accessible
service".  If they want to schedule something at a "bad time",
that's their problem.
But, other tasks can have built-in heuristics that can provide hints
to when they should be scheduled IN THE ABSENCE OF SPECIFIC
CRITERIA FROM THE USER.
E.g., we irrigate at night.  This is done because there are less
evaporative losses.  And, because it is unlikely that users will
want to take showers at 3AM.
If the user overrides (cancels) such an action, the task
knows that the need for irrigation water still exists (just
because you don't want to irrigate now doesn't mean the
plants suddenly stop needing water).  So, it tries to
find a better time.
Or, if the user explicitly gives it a better time (periodic
or aperiodic), then it learns from these preferences.

I have my own bias, I want computers to do what I want.  For
expample, when I make a break I prefer to have some special
combination of keys to put system to sleep _immediately_.

Yes.  Hence the "SLEEP" option in the start menu.

When I work, I may think for longish time, and systems that
go to sleep based on "inactivity" distract me (especially
when I am trying to understand a text or a picture on the
screen and the screen goes blank).

That requires adjusting the sleep interval.  I often leave
a workstation for some other activity.  I would be annoyed if
it DIDN'T go to sleep after I'd been "gone" (inactive) for 30
minutes.
OTOH, I've been scanning legal documents on my larger scanner.
It is networked so need not be located proximate to my
workstation.  I can control it and retrieve scans without
being AT its side (though I need to be so to load new documents).
Often, I have to post-process a scan (e.g., if I have "receipts"
that I might want to scan alongside a document and, later,
"cut them off" as separate pages).  While I am doing this,
the scanner often times out.
This is annoying as I have to restart the application.
(There is no obvious timeout value for the *application*,
though there is for the connection to the scanner).
But, tolerable.  Compared to the time required to walk
over to the scanner (in another room to conserve on desk
space in the office), arrange the documents, walk back
to the workstation, perform a "preview" scan so I can
determine what portion of the flatbed is important, do
a real scan, and then import to photoshop, etc.
[A control in the scanning application that would let me
set the timeout -- or, disable it -- would be welcome]