battery-saving architecture

3.27: addx/batt'saving architecture:

notifications:
. without notification systems or hardware interrupts
ipc (interprocess communication) requires
a polling loop which uses power all the time
just checking for whether anything needs power!
. notifications work by having service agents
tell the os what they are checking for,
and then the os will call them back when it happens .

power-saving mode:
. another needed control system is batt'savings mode;
because, agents can provide
higher levels of service if they know
whether the user has nearby access to more batt's .

. services can vary their levels of service by
putting optional services in a separate thread,
and then marking that thread as optional
which then affects its scheduling priority .
. the user can indicate how much to conserve,
and then the system sets a power.conserve.flag .
. the scheduler can use that flag
to adjust the way it schedules the optionals .

. put all optional work on a todo,
else if it's now-or-never,
tell the user what's not being done
while on min drain mode .
. another option while employing a user agent
is letting the agent handle the annoying,
repetitive questions from a service .

. the os uses the average recent rates of cpu useage
to estimate relative batt'life or work levels .
. the os also considers batt's charge age:
if the batt' is near the end of life,
then optional services should be cut anyway
since being in that state worsens the amount of
batt'drain per work done .

. if the system is working more than minimally,
it can then ask the user
whether they'd rather have more batt'life .
. it could do this with an alert
or an on-going notification (animated icons)
for both work intensity and remaining energy;
but, on some systems,
the remaining energy is not easy to measure .