Python Basic Learning Log day10-event-driven model

On event-driven and asynchronous IO

Original: Http://www.cnblogs.com/alex3714/articles/5248247.html often, when we write the server processing model of the program, there are several models:

(1) Each request is received, a new process is created to process the request, and (2) Each request is made, a new thread is created to process the request, and (3) each request is placed into a list of events, which allows the main process to process the request in a non-blocking I/O manner, with a variety of different ways, The method in paragraph (1), because the cost of creating a new process is relatively large, it can result in poor server performance, but the implementation is relatively simple. (2), due to the synchronization of threads, it is possible to face deadlock and other problems. In the form of (3), the logic is more complex than the previous two when writing the application code. Taking into account all aspects, it is generally accepted that the first (3) approach is the way most Web servers are used to talk about event-driven models

In UI programming, it is often necessary to click on the mouse to the corresponding, first how to get a mouse click?
Mode one: Create a thread that has been looping through the detection of mouse clicks, and there are several drawbacks to this approach :
1. CPU waste, may be mouse click frequency is very small, but the scan thread will still be cyclic detection, which will cause a lot of CPU waste, if the scan mouse click on the interface is blocked?
2. If it is blocked, and will appear the following problems, if we not only to scan the mouse click, but also to scan the keyboard is pressed, because scanning the mouse is blocked, then may never go to scan the keyboard;
3. If a cycle needs to scan a lot of devices, which will lead to response time problems;
So, the way is very bad.

Mode two: Is the event-driven model
Most of the current UI programming is an event-driven model, as many UI platforms provide the OnClick () event, which represents the mouse down event. The event-driven model is broadly thought of as follows:
1. There is an event (message) queue;
2. When the mouse is pressed, add a click event (message) to this queue;
3. There is a loop that continuously extracts events from the queue, depending on the event, calling different functions, such as onclick (), OnKeyDown (), etc.;
4. Events (messages) generally hold their own handler pointers, so that each message has its own processing function;

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.

Here is a question, that is, in the event-driven model above, as long as an IO to register an event, and then the main program can continue to do other things, only to the completion of IO processing, continue to restore the previously interrupted task, how is this essentially implemented? Haha, here we come together to uncover this mysterious veil ....

Python Basic Learning Log day10-event-driven model