INTERRlJPI' HANDLING
The central logic of this approach assumes that there is a "list" of poosible interrupt sources to be scanned, and that passing through this list may uncover one (the usual case), multiple, or zero events that require responses. To illustrate the second two cases, assume that the possible events are labelled A through K, and that the interrupt handler tests for A, then B, and so on. Assume also that event B occurs follCMed quickly by event J. The interrupt handler is invoked for event B, shortly thereafter the IP updates J' s indicator and emits a second interrupt pulse, which is latched. The handler scans its list of event indicators, finds that both B and J have occurred and responds to them both. Reaching the end of the list, the interrupt handler enables the IP interrupt and returns. Imnediately, J's latched interrupt request is recognized and the handler is invoked again. This time, however, it will find no events indicated in the IP processor data segment, since it responded to both B and J in the previous invocation. It will simply clear the interrupt latch, pass through the list, unmask the IP interrupt, and return, effectively making a null response.
Table
