signals

7.27: adda/cstr/signals:
7.30: intro:
. pyqt signals are a system of inter-object communication;
any object can emit a signal
to convey that some event has occurred;
and, any other object may connect a signal handler
to be launched whenever a particular object
raises a particular signal .
. signals can return any sort of record,
and the corresponding signal handlers
are expected to declare their parameter's type
to be the same type as the signal's returned record .
. pyqt sees signals as launching slots
and then the act of connecting a signal handler
is filling such a slot with a subprogram .
. there can be multiple connections to a slot,
so the slot is often filled with multiple handlers .

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 .

notifications support

3.16: adda/notifications:

. after reading about dev.mac's notification system
I'm wondering how adda, too,
can provide this service .
. existing parts of adda should be reused
when possible;
eg, all coprograms having mailboxes .
[3.29: coprograms include all concurrent processes:
coroutines, tasks, type-mgt's,
and other background services .]

multi-level interfaces:
. you can see notifications in action
during a debug watch-point command:
that makes execution stop at
any code that modifies a given obj .
. this is economically possible because of
the multiple levels of interface
where all the high-level entries
use just one low level write function;
so, then an obj's write function
can be replaced with a
(call me instead of writing);
likewise, in the same way that
classes can be subclassed,
objects within the same class can be
individually customized
so as to facilitate notifications .

3.17:
. this can be done while still
reusing class functions
by having every object include
along with a tag
a watched bit for impl'ing notifications .
. the way to identify an object
is that every object
-- even when on the stack rather than heap --
is part of a process with an id#
and then part of a call path:
eg, process#2/sub1/sub2
. or,
every object is part of an act'rec ...
(this needs a proof,
but the future looks bright);
anyway,
the run-time exec' is checking the watched.bit
during each object access,
and if it's set,
then it's got that obj's id,
which is used to look up the object
in a notification database
to see what about the object is customized .
. the db can provide
the conditions under which
notifications need to be sent out,
and can also keep the list of
which mailboxes should be notified,
or what actions need to occur
if a certain trigger is set .

3.16: addm/notifications:
. assuming every obj has a watched bit
for impl'ing notifications:
. a problem with letting arbitrary obj's be watched
is it brings down performance across the entire system
regardless of how little
the watching feature is used ?
. for obj watching to be efficient,
have 2 versions of addm:
one will be checking the watch bit,
while the other version will ignore it .
. every process has a pointer indicating
which virtual processor it's being run on .