Talk:Interrupt handler

"event handler" vs. "interrupt handler"

event hander 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

Motorola in MC68332 data sheets mentions events as triggering hardware on that automotive MCU with on chip peripherals. It included a timer unit for engine control. Event is not a cpu term. The change caused by the event is what the cpu acts on. TaylorLeem (talk) 00:45, 6 July 2020 (UTC)

This appears to be quoting the edit summary of this edit, which removed from the article a paragraph saying:

Note: the term interrupt handler is an older computing term which has generally been superceded by the newer term event handler.

For what it's worth, I've never heard people referring to the routine that responds to an interrupt as an "event handler", so I tend to agree with the edit summary and the edit in question. Guy Harris (talk) 08:37, 2 June 2023 (UTC)

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)

Not to mention that this article is fairly hard to understand if you don't aren't a software engineer.. 130.102.0.175 (talk) 03:38, 21 October 2009 (UTC)

New material trial balloon

I just added quite a bit of new material, in an attempt to shift the balance of coverage. My tone has probably veered into OR at various points. My sense is that this article should say enough that a young programmer wanting to try his hand at writing an interrupt handler is at least aware of the major demarcations and pitfalls.

I'm not wedded to anything I've added. It was a one-and-done affair, so have at it if it seems unsuitable. I thank you if you try to retain at least some semblance of a reasonable overview for a reader who might be poised to dive into this sometimes harrowing world.

Also, I don't know how many times I used the word "typically". Was there a word I wrote where I couldn't think of a major exception? Probably not. There was a temptation to put a statement in the lead: "interrupt facilities come in every imaginable combination and permutation, what we describe here are some of the prototypical cases".

In one of my earliest programming projects, the interrupt dispatch table ended up in mask ROM. Not EPROM. Mask ROM. Anyone who wants to term that a "call back" (as this article recently did) will do so over my cold, dead, geriatric cadaver :-) — MaxEnt 01:18, 29 April 2017 (UTC)