| Event-driven Programming |
Website Links For Programming |
Information AboutEvent-driven Programming |
| CATEGORIES ABOUT EVENT-DRIVEN PROGRAMMING | |
| programming paradigms | |
| event computing | |
|
OVERVIEW Instead of waiting for a complete command which may order it to process information, the system is preprogrammed with an Event Loop , to look repeatedly for information to process (whether this might be the appearance of a file in a folder, a keyboard or mouse operation, or a timer event) and then perform a ''' Trigger Function ''' to process it. Programming an '''event driven''' system is thus a matter of rewriting the default trigger functions of the system, to match the required behavior. The method by which information on events is acquired by the underlying system is immaterial. Inputs can be Polled in the event loop, or Interrupt Handlers can be registered to react to hardware events; many systems use a mixture of both techniques. The preprogrammed algorithm ensures that triggers provided are executed when they are needed, thus providing a software abstraction that emulates an interrupt driven environment. Event-driven programs typically consist of a number of small programs called Event Handler s, which are to be called in response to external events, and a Dispatcher , which calls the event handlers, often using an Event Queue to hold unprocessed events. In many cases event handlers can trigger events themselves, possibly leading to an Event Cascade . Event-driven programming stresses flexibility and Asynchrony as virtues, and tries to be as Modeless as possible. Graphical User Interface programs are typically programmed in an event-driven style. Computer Operating System s are another classic example of event-driven programs on at least two levels. At the lowest level, Interrupt Handler s act as direct event handlers for hardware events, with the CPU hardware performing the role of the dispatcher. Operating systems also typically act as dispatchers for software processes, passing data and Software Interrupt s to User Process es that in many cases are programmed as event handlers themselves. A Command Line Interface can be viewed as a special case of the event driven model in which the system, which is inactive, awaits one very complex event--the entry of a command by the user. EXAMPLE This example uses pseudo code to illustrate how data is read from a socket using an event driven approach: function read_next_data(fd) data = read_async( fd ) if len(data) == 0 => Nothing to read, register to be called back when something is ready event_polling_register( fd, read_next_data ) => Go back to doing something else else => Data was available and len(data) was received add_data_to_buffer( buffer, data ) fi REFERENCES
SEE ALSO
EVENT-DRIVEN FRAMEWORKS AND LIBRARIES
EXTERNAL LINKS
|
|
|