Event Driven Computing
• Basic Interaction Handling
– Interactive programs - must pay attention to the user interface
walters@buffalo.edu
480/580 Lecture 2
Slide 1
Human Factors
1) Provide simple and consistent interaction sequences
eg. each window has same mouse button functions
2) Don't overload user with options - KISS
3) Show available options clearly at every stage of
interaction
Don't expect user to remember
Place info accessibly but not so it interferes with advanced user
4) Give feedback to user
Examples in your window manager? - highlights, key echos
5) Allow user to recover gracefully from mistakes
Allow for arbitrary input
Cancel, undo
walters@buffalo.edu
480/580 Lecture 2
Slide 2
Logical Input Devices
• Used by graphics packages to provide deviceindependent code
• Locator - specify screen coordinates and maybe
some state buttons
• Keyboard - alphanumeric input
• many others
walters@buffalo.edu
480/580 Lecture 2
Slide 3
Event Driven Computing
How different from programming with simple user
input and an emphasis on internal computations?
Example A:
Read array of integers,
Sort them, largest first,
Print the sorted array.
Example B (ATM machine):
W: wait for signal that card has been inserted,
Take care of transaction,
Go to W.
walters@buffalo.edu
480/580 Lecture 2
Slide 4
• In A the program determines the sequence of
instructions
• In B the users largely determine the sequence
• B is an example of interrupt driven computing
– An “Interrupt” is the signal that is produced when a
physical even is sensed by one of the peripherals of a
machine
– What are the possible interrupts for the ATM machine?
• Example Interrupt Driven Computing (ATM):
– If an interrupt occurs
• call interrupt_handler (kind_of_interrupt).
– Repeat above.
walters@buffalo.edu
480/580 Lecture 2
Slide 5
• Programs with Graphical User Interfaces require
interrupt driven computing
– Not because of the geometric aspects of the display and
pictures, etc
– But because the program has to wait for signals from
the user and execute the appropriate action for each
signal received
walters@buffalo.edu
480/580 Lecture 2
Slide 6
Events
• Programs running under operating systems such as Unix
cannot directly sense physical interrupts
• What part of the system handles interrupts?
• Operating system can pass info about interrupts to
program in two different ways
– signal the program immediately
• program samples or polls a logical input device looking for state changes
• continuous sampling required by the application program
– store the info in a place that the application program can check it
• In window systems the structures containing information about physical
interrupts are called “events”
• place stored called “event queue”
• event driven computing
walters@buffalo.edu
480/580 Lecture 2
Slide 7
• Events are more general than interrupts
– can be used to pass info about things that are not physical
interrupts
• Events are associated with “event-triggers”
– a user action that causes an event to occur
walters@buffalo.edu
480/580 Lecture 2
Slide 8
• Example: Event Handling Program:
– Check whether an event has occurred
• and it if has, then call event_handler(kind_of_event)
– Repeat above
• Compare to Interrupt Driven Computing (ATM):
– If an interrupt occurs
• call interrupt_handler(kind_of_interrupt)
– Repeat above.
• Appear similar - big difference if program has to perform
significant other computations
– interrupt driven jumps from current computation to service
interrupt when it occurs
– event driven doesn’t notice event until it checks for it
• problem of user feedback - type-ahead versus draw-ahead
walters@buffalo.edu
480/580 Lecture 2
Slide 9
Review
• Standard programming versus interaction based
programming
• Sampling (Polling) versus Event handling of
interactions
• Interrupt-driven versus Event-driven
walters@buffalo.edu
480/580 Lecture 2
Slide 10
Two programming styles for event handling
• Response to same event needs to differ at times
– what are the input devices on an ATM?
– Eg. ATM
• typing in PIN number, typing in withdrawal amount, etc.
• Nested event handlers
• only one sequence of accepted events valid
• infinite wait loops inserted were needed
• code dealing with events spread throughout so harder to make
portable between window systems
• State variables
•
•
•
•
only one sequence of accepted events valid
only one wait loop
code dealing with events in one place - easier to make portable
encourages modular programming
walters@buffalo.edu
480/580 Lecture 2
Slide 11
walters@buffalo.edu
480/580 Lecture 2
Slide 12
walters@buffalo.edu
480/580 Lecture 2
Slide 13