Re: Portable End_Error handling desired

[eachus@mitre-bedford.arpa (Robert I. Eachus)]

In article <1991Nov20.011726.4124@milton.u.washington.edu> mfeldman@milton.u.wa
shington.edu (Michael Feldman) writes:

   Hmmm. I don't really think recursion is necessary to guard against
   strange input from the keyboard; a loop will do...

   But it is!  There are two cases.  First, I'm sure that you realize
that every I/O read must be done in the scope of an exception handler,
even if the read is in an exception handler.

   Second, and not really described anywhere in Ada books because it
is an operating system thing is that for I/O you should always be in
the scope of multiple handlers.  The problem is that when you get to
the exception handler, you MUST be ready to immediately field another
exception.  On computers without time sharing the situation occurs
only infrequently, but on a time shared machine it is hard to avoid a
situation where the input handler queues signals for two or more
separate exceptions/conditions/interrupts while your process is
inactive.

   Polite OS's will give your process a few microseconds to cope with
the first signal, but don't count on it.  I usually do attempt to deal
with more than two signals back-to-back though.  For example, most
systems will queue a "wake up I've got input" just once, but are quite
willing to follow that immediately by a break (or file closing).  This
sounds like what you are hitting.  (And yes, it would be nice if the
Ada run-time could handle the race condition cleanly, but on some
systems (hardware or operating) it just is not possible, and you have
to be ready to deal with the situation.


					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...