RE: Hmmmm.....$1 Billion

> From: Steve Richter
> 
> the way I understand it, events are the equivalent to interupts.

No no no!  The two are completely different.  When programming an
event-driven system, you need two distinct classes of code: tasks and
interrupt handlers.

A task is something that sits quiescently and waits for an event to be
passed to it.  Typically tasks are prioritized and scheduled by a task
scheduler, which oversees all the work.  Tasks typically read these
events from a queue, and can execute (comparably) long-running
processes, then return to the queue to determine the next event to
process.  In the simple scenario of a single-CPU environment, typically
(though not always) a task is allowed to run until it is done, at which
point the next task in the list gets the processor.  (OS/400 goes beyond
that with priority-based task pre-emption, time slicing and a number of
other very sophisticated task management features.)  But the point is
that a task can get busy and stop processing events, or even get
cancelled.  The events will continue to get queued, but they won't be
processed.

Interrupts, on the other hand, occur immediately upon the recognition of
a hardware event.  This may be a keypress, a mouse action, or an I/O
port.  Interrupts by design are very fast, very simple routines, that
INTERRUPT the currently executing task.  Again, in the simple single-CPU
model, the interrupt immediately takes over the CPU, saves the state of
the machine, executes the interrupt code, and then restores state.
Typically, an interrupt's job is to package a message and put it on a
queue, although more sophisticated interrupt handlers may be designed
that actually block input into buffers.

Joe