This is bang-on, and takes me back to writing word processing code in assembler back in the late 70s.

When an interrupt happens, the processor suspends whatever it's doing; it stuffs all of the register values, including the program counter, onto a stack, then calls the appropriate interrupt service routine. When that (very slim) routine is finished, it executes not a normal RET (subroutine return), but an RTI (return from interrupt) which pulls not only the program counter from the stack, but the values of all the registers. Thus, as far as the original code knows, nothing happened (OK, this depends on the processor architecture, but you get the idea).

Even cooler -- while an interrupt is being processed, that level of interrupt and everything below it is disabled, which means any interrupt that happens during the routine is ignored until the RTI is executed. If a higher level interrupt occurs, the obvious happens -- registers are pushed, and the processor again jumps to another interrupt service routine.

So, when an event occurs, you want to have the shortest (fastest) possible interrupt service routine handle the event, so that the processor can get back to whatever it was doing, such as drawing text on the screen, processing keyboard input, or waiting in an idle loop, without dropping any data. The idle loop runs around and waits for things to magically appear in the queues, via the interrupt service routines. It can then do the laborious process of figuring out what complicated processing needs to be done with the keystroke, without the worry that another event is going to come along and perhaps be dropped.

Problems occur when the interrupts come too thick and fast for even the slender interrupt service requests to deal with -- either that of the code that handles the incoming data can't empty the queues fast enough.

Fun stuff, and good to remember in this context.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds


In reply to Re^2: How to wait for events, and not lose any, while processing them ? by talexb
in thread How to wait for events, and not lose any, while processing them ? by Eyck

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.