Talk:Interrupt handler

From Wikipedia, the free encyclopedia

event handler is a general term, it has not superceded interrupt handler

Opinions anyone? ⇒ normxxx| talk ⇒ email 04:43, 20 March 2006 (UTC)

Why do you think it has? Jsmethers 05:59, 21 March 2006 (UTC)
Well, that was admittedly my subjective impression. The term "interrupt" dates back to the beginning of computing (when there were only one or very few physical interrupts allowed: I/O, clock, initial loading, etc.). Nowadays, even simple computers come equipped with over a hundred (assignable) "interrupt" vectors and from the point of view of a SLIH, for example, it does not much matter if it is activated by a FLIH or some other asynchronous event. Moreover, it is hard to think in terms of an "interrupted program" when, in a priority OS, we may have several dozen (or more) nested "interrupted" processes.
You would be hard pressed to find OS literature that did not use the term interrupt handler to refere to the handlers in the OS's interrupt subsystem. Event handler is very general while Interrupt handler is very specific to what is being handled. Maybe you could give some specific examples of the use of event handler? Nothing plausible comes to my mind outside of the network stack. Jsmethers 04:04, 22 March 2006 (UTC)
Hence, the tendency to call all such "events."
Hardware interrupts are typically called interrupts, not events. Event fits simply because it is more generic. Events are typically used to mean software notifications, state, or procedure calls. To me, usage of event seems very specific to academic use in the software engineering profession. Jsmethers 04:04, 22 March 2006 (UTC)
But, properly speaking, we need to have a very restricted poll of OS writers/maintainers. Do you know what Microsoft's take is; since they now dominate the field? ⇒ normxxx| talk ⇒ email 23:01, 21 March 2006 (UTC)
I prefer usage in the order of industry terminology followed by academic terminology to any specific company's terminology. But to answeer your question, it seems that interrupt service routine is used by Microsoft (most likely because of MSDOS origins). Jsmethers 04:04, 22 March 2006 (UTC)
A short list of books, all of which do not even mention the term event with respect to interrupt handlers. These books only use event in conjunction with process and thread schedulering and waiting.
  • Mauro, Jim. McDougall, Richard. SOLARIS Interanls, Sun Microsystems Press, 2001. ISBN 0-13-022496-0
  • Solomon, David A. Inside Windows NT: Second Edition, Microsoft Press, 1998. ISBN 1-57231-677-2
  • Vahalia, Uresh. UNIX Internals: The New Frontiers, Prentice Hall, 1996. ISBN 0-13-101908-2
  • McKusick, et. al. The Design and Implementation of the 4.4BSD Operating System. Addison-Wesley Publishing Company, 1996. ISBN 0-201-54979-4
  • Schimmel, Curt. UNIX Systems for Modern Architectures, Addison-Wesely Publishing Company 1994. ISBN 0-201-63338-8.
  • Bach, Maurice. The Design of the UNIX Operating System, Prentice-Hall, Inc. 1986. ISBN 0-13-201799-7

[edit] Wrong

This article gets the terminology mostly wrong.

Traditionally, a first-level interrupt handler is part of the "bottom half" of the device driver, and the second-level interrupt handler is part of the "top half" of the device driver.

(Linux, and this article, has them the wrong way around. See e.g. McKusick et al.)

The "top half" also includes code which is not related to interrupt handling and does not need to run in interrupt context, e.g. device configuration and the transmit path.

The "bottom half" may also include code which is not related to interrupt handling but does need to run with interrupts disabled, e.g. timing-sensitive parts of the transmit path.

Interrupt threads are orthogonal to this. An interrupt thread is a separate thread that runs the second-level interrupt code; you won't find interrupt threads in non-threaded kernels such as the 4.4BSD kernel, FreeBSD prior to 5.x or Linux prior to 2.4.x. Note that the interrupt thread does not run all of the "top half"; parts of the "top half" run in the context of whichever process is reading from or writing to the device.

DES 13:30, 31 July 2007 (UTC)