Differences between version 5 and predecessor to the previous major change of InterruptHandler.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 5 | Last edited on Monday, October 18, 2004 3:51:25 am | by AristotlePagaltzis | Revert |
| Older page: | version 4 | Last edited on Monday, October 18, 2004 3:18:36 am | by AristotlePagaltzis | Revert |
@@ -1,7 +1,5 @@
-A section of code run
whenever an interrupt
occurs. These may be at
the application level or at the OperatingSystem's level
. They
are notoriously hard to write because they occur asynchronously with the rest of the application or OperatingSystem
. Hardware interrupts can
also happen __very__ frequently, so their handlers are commonly written in AssemblyLanguage
.
+A section of code invoked by the hardware
whenever an [IRQ]
occurs. It is generally part of
the [Kernel] and usually contained in a device driver
. Because they occur asynchronously, invoked by hardware rather than through normal control flow, InterruptHandler~s
are notoriously hard to write. They are
also commonly written in AssemblyLanguage because [IRQ]s tend to
happen __very__ frequently.
-Generally,
the term "interrupt" is used for hardware-generated requests
, while "signal" is used for software/OperatingSystem-generated requests
.
+One specific InterruptHandler is of paramount importance in modern OperatingSystem~s:
the timer [IRQ] invokes a handler which drives the scheduler that distributes [CPU] time among tasks. Without this [IRQ] and its handler
, preemptive multitasking would not be possible
.
-See also:
-*
[IRQ
]
-*
[Signal]
+Note that this is different from a
[Signal] handler, which is called by the [Kernel
] through normal control flow means. Note that software can trigger interrupts, and InterruptHandler~s sometimes send
[Signal]s. The concepts remain distinct, though, despite having many things in common.
