Python2.0_s12_day9_ Event-driven programming & asynchronous IO

On event-driven and asynchronous IO

Event-driven programming is a programming paradigm where the execution flow of a program is determined by an external event. It is characterized by the inclusion of an event loop that uses a callback mechanism to trigger the corresponding processing when an external event occurs. Two other common programming paradigms are (single-threaded) synchronization and multithreaded programming.

Let's use examples to compare and contrast single-threaded, multithreaded, and event-driven programming models. Shows the work done by the programs in these three modes over time. This program has 3 tasks to complete, each of which blocks itself while waiting for an I/O operation. The time it takes to block the I/O operation has been marked with a gray box.

In the single-threaded synchronization model, the tasks are executed in order. If a task is blocked by I/O, all other tasks must wait until it is complete before they can execute sequentially. This explicit execution sequence and serialization processing behavior is easily inferred. If there is no interdependent relationship between tasks, but still need to wait for each other, this makes the program unnecessary to reduce the speed of operation.

In a multithreaded version, these 3 tasks are executed separately in separate threads. These threads are managed by the operating system, can be processed in parallel on multiprocessor systems, or interleaved on a single-processor system. This allows other threads to continue executing while a thread is blocking a resource. This is more efficient than synchronizing a similar function, but programmers must write code to protect shared resources from being accessed by multiple threads at the same time. Multithreaded programs are more difficult to infer because such programs have to handle thread-safety issues through thread synchronization mechanisms such as locks, reentrant functions, thread-local storage, or other mechanisms, which can lead to subtle and painful bugs if implemented improperly.

In the event-driven version of the program, 3 tasks are interleaved, but still in a separate line-controlled system. When processing I/O or other expensive operations, register a callback into the event loop and continue execution when I/O operations are complete. The callback describes how to handle an event. The event loop polls all events and assigns them to the callback function that waits for the event to be processed when the event arrives. This approach allows the program to execute as much as possible without the need for additional threads. Event-driven programs are more likely to infer behavior than multithreaded applications because programmers do not need to be concerned about thread safety issues.

The event-driven model is usually a good choice when faced with the following environments:

1. There are many tasks in the program, and ...
2. The tasks are highly independent (so they don't need to communicate with each other, or wait for each other) and ...
3. Some tasks are blocked while waiting for an event to arrive.

This is also a good choice when applications need to share variable data between tasks, as there is no need for synchronous processing.

Network applications often have these characteristics, which makes them well suited to the event-driven programming model.

select\poll\epoll Asynchronous IO

Http://www.cnblogs.com/alex3714/p/4372426.html

Python2.0_s12_day9_ Event-driven programming & asynchronous IO