* Re: Interrupt handlers and exceptions
1998-06-12 0:00 Interrupt handlers and exceptions Samuel Figueroa
@ 1998-06-18 0:00 ` Robert I. Eachus
0 siblings, 0 replies; 2+ messages in thread
From: Robert I. Eachus @ 1998-06-18 0:00 UTC (permalink / raw)
In article <6lrurs$4fm$1@news2.apple.com> SamuelFigueroa@no_spam.usa.net (Samuel Figueroa) writes:
> Paragraph 7 of Section C.3 of the ARM says that exceptions cannot be
> propagated from interrupt handlers. Does this mean that an interrupt
> handler cannot raise something like Constraint_Error, and expect a task's
> exception handler to be invoked?
Exactly. Consider an interrupt to be like a task whose entries
have no body. If an exception would propagate out of an interrupt
handler, it is silently discarded, just like when an exception
propagates out of a task.
> Is there any way for an interrupt handler to cause a task's
> exception handler to be invoked, or to somehow cause the
> termination of the task that was executing when the interrupt
> occurred? (For the purposes of this discussion, one could envision
> an interrupt handler for page faults, in which one might want to
> raise some exception, and either have the program's exception
> handler take some action, or terminate the program itself.)
The key here is that you don't KNOW from a language point of view
which task caused a handler to be invoked. In the particular example
you use, the interrupt handler can determine which task caused it to
be invoked, but the process for doing that is outside the language.
(For example, on some hardware the interrupt stack is completely
separate from the user stack.)
If you had a situation where the interrupt was directly invoked by
a call, you could wrap the call in a procedure that checked a variable
for a return code, or you could even have the compiler provide another
package like Ada.Interrupts, where the handlers were functions that
provided return codes. However, in your page fault example, there is
noplace for that return code to go.
Having faced this problem in operating systems, the best solution
is to have the page fault handler always succeed. When you get close
to running out of (backing store) memory the interrupt should send a
message to the operating system, write to logs, etc., then return.
Any error handling when you are completely out of memory is, to use an
idiom from Dave Emery, a parachute that opens on impact. There is
nothing you can do then which is better than crashing the machine.
To clarify, the process which ate (almost) all of the memory may
not be the one that reaches for that final kilobyte. If you kill
processes to free space, eventually you will kill the right one, but
by then you will have either corrupted the disk or killed key
processes in the OS. So the choices are to do bad things, then crash,
or crash immediately and hope that the villain can be found in the
dump--if you have a tape to dump to.
Much better is to write the code for recovering from storage
exhaustion, figure out how much memory you need to run it, and
allocate that memory ahead of time. Of course the first thing that
job does, as part of the interrupt handler, is to turn off page fault
interrupts. So, yes, that means you have to have at least one page of
code resident, and then use that to carefully swap in the rest of the
necessary code from disk without using the virtual memory support. I
think I only know of three OSes that ever got this code to work right.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [flat|nested] 2+ messages in thread