exception mgt

11.9: adda/exception mgt/intro:
. we expect some errors;
because, we'd like to
use some software before having to
formally verify its correctness,
so, we compensate
by finding ways to limit damage:

# isolation:
. modules should never crash other modules:
we can verify a microvisor or microkernel,
and it enforces the firewalls between processes .
. addx should be such a microkernel design;
[11.12: just as the app doesn't have
direct access to the user (it's the mvc`model
while adde is the view&controller )
it also has no direct access to the machine:
all c-level activity is handled by addx|addm .]

# regularly yielding to the gui coroutine:
. a critical priority of addx
is never letting the gui be unresponsive;
this is done by having adda embedding calls to addx
at every place in a subrogram that could
mean more than a milisec of cpu time:
# inside every function call,
# inside every loop .
. this is cooperative multi-tasking with
system-enforced coroutine yielding
for paravirtualizing true multi-tasking .

# regular reporting to supervisor:
. getting a regular progress report
will limit waiting on the down employee .
. employees can be waiting on
down service providers;
loops can be waiting on a terminal condition
that never arrives;
as when there's unexpected input;
mutual recursions (eg, f->g->h->f)
are another form of looping;
deadlocks can cause indefinite waiting,
but those can be avoided by
proper use of concurrency,
and by not locking resources
(using queues instead).
. a subprogram can be waiting because of
a failure to establish dialog with the user
(eg, if the system allows a window to be
always on top,
then dialog windows may be hidden from view).
. all threads are periodically tested for
whether they're waiting for a job offer,
for a {service, resource},
or are performing a service;
in which case,
addx measures how long ago the thread
produced its latest progress report .
. the progress reports read like a narrative
that a human would appreciate;
to make these reports quick,
msg's are encoded, so that each msg
is represented by some value in a byte (0...255)
(or a 16-bit integer if this subprogram had
more than 256 msg's).

# blackbox recorder:
. it tells us what was going on
just before a crash .
. it saves the progress reports,
and the recent call chain .

# a debug mode:
. when users' tools are not working well,
some users may like to see what's wrong
by using developers' visualization tools;
eg,
a freezing problem can be illustrated
as a looping call chain:
. the tool collects all the recent calls
(saved by the blackbox recorder)
then tries to find a recursion,
and shows the list of calls that are repeated .

11.8: sci.adda/exception mgt/reporting#loop count approximations:
[11.11: obs:
. it would be better to use progress reporting .]
. if adda can't statically figure out
when a loop won't terminate,
it should remind coders to give
approximate loop counts;
then the run-time can use that how?
sci:
. before the loop entry,
adda sets the counter, and a limit,
then has the scheduler check the limit .
. scheduler doesn't have to check all the time;
but if 2sec's go by,
nearly all loops are done by then,
if there is no limit given,
it starts giving it more cpu time if it can,
so the real time is compressed,
if another sec goes by
and there's other jobs to do,
then it starts getting starved ?
it could be doing a huge job!