11.python Concurrency Primer (part13 Understanding event-driven model))

First, the introduction of the event-driven model.

Before introducing the event-driven model, let's review the traditional pipelined programming.

Start---> code block a---> code block b---> block c---> Block d---...---> End

Each code block is a code that accomplishes a variety of things, but the programmer knows the code block a,b,c,d ... Order of execution, the only thing that can change this process is data. Enter different data, judging by the conditional statement, the process may be changed to a--->c--->e ...---> End. Each time the program may run in a different order, but its control flow is determined by the input data and the program you are writing. If you know the current running state of the program (including the input data and the program itself), then you know that the next step is even until the end of its running process.

The general execution flow of the event-driven model:

Start----> Initialize----> Wait

When a program based on an event-driven model executes, it begins to wait for an event to be triggered. (In fact, waiting for an event to be triggered, in the traditional pipeline programming also has, "wait" situation exists, for example, a raw_input will cause the program to wait for the user to input a data. However, you need to know that these two waits are different!

Pipeline programming "Wait" is the programmer of the program know in advance, or need to force the user of the program to enter some data.

But the "Wait" in the event-driven model does not know exactly what the user of the program is going to do, and when something happens (for example, a mouse is clicked, a keyboard key is tapped, and the system's internal timer is triggered). The program will react accordingly.

Second, the event-driven model is briefly introduced.

Commonly used event-driven models can be divided into 3 categories.

1. When each request is received, a thread is created to process the request.
   

2. When each request is received, a process is created to process the request.

3. When each request is received, a request is placed in the event list, allowing the main process to process the request through a non-blocking I/O mode. # (This method refers to the way the co-event is driven.) ）

Suppose, now you need to create a thread that uses a dead loop to detect whether a user's mouse has a click action.

1. First, using the dead loop to detect whether the mouse has a click action is a waste of CPU resources!
   

2. If the mouse is detected if the interface is blocked, the program stops here, and will cause another problem, if this time also to detect whether the keyboard is pressed, (there are multiple events need to be detected), detect whether the mouse is pressed interface is still blocking state, the next will never go to detect the keyboard.

So now that most UI programming is based on the event-driven model, most UI programming provides an OnClick () event that represents a mouse-down event, and the general model of the event processing is as follows:

650) this.width=650; "title=" "src=" http://img.blog.csdn.net/20161012022913536 "alt=" here write a picture describing "style=" width:690px; "/ >

First Look at:

1. The event-driven model, first of all, is to have an event list (this list is equivalent to Message Queuing).

2. Once the mouse is clicked, an event (message) is added to the event list (message queue).

3. At this point, there will be a loop that constantly takes events from the event list (message queue) and invokes different functions based on different events.

4. The event (message) has a separate handler function.

This article is from the "Rebirth" blog, make sure to keep this source http://suhaozhi.blog.51cto.com/7272298/1926755

11.python Concurrency Primer (part13 Understanding event-driven model))