The Hollywood principle is "Don't call us, we will call you to inform you". In fact, this is the reactor mode. You don't have to keep asking if an event has happened. When it happens, you will be notified. It is generally used to process concurrent requests on the server. Let's take a look at several participants in the reactor mode.
- Event processor: corresponds to a descriptor to implement the services provided by the application on this descriptor.
- Reactor MANAGER: Scheduling core of the event processor. Used to control event scheduling and register and delete event processors and related descriptors. The reactor Manager uses a synchronization event splitter to wait for an event to occur.
- Demultiplexer: used to wait for one or more events. The caller is blocked until an event occurs in the descriptor set separated by the splitter. For example, select in Linux is a separator.
What an application needs to do is implement an event processor and register it in the reactor Manager. The subsequent event scheduling work will be completed by the manager. The reactor manager is at the core of the entire framework design, shouldering the separation and scheduling of events. Imagine an example of multi-user concurrent access to experience the role of reactor. Now the restaurant has five groups of guests at the same time. The traditional thread pool approach is to allocate a waiter (thread) to each group of guests (requests ). Reactor's practice is that the waiter Tom first greeted group A's guests, asked group A's guests to slowly take a look at the recipe, then greeted group B, and then went on in sequence. When group A ordered the food, the waiter will be greeted with "yes". Tom will then greet group A's guests and enter the menu for group A's guests. This will greatly improve the efficiency of the restaurant and save manpower. If this is a server that processes client requests concurrently, one request and one thread may seem reasonable, but it will consume a lot of system resources. However, if these customer requests do not require the server to process them all the time, that is, there is an I/O event (the server reads the data sent by a through the socket between them after receiving the request from Client ), at this time, the corresponding server thread can be used to process other requests, but after reading a, the server will be notified to continue to process Client A's requests. This requires a set of libraries to help the server program complete these scheduling. The server program only needs to provide the processing functions when the request comes and an I/O event occurs, the problem of how to allocate threads and Thread Scheduling for concurrent request access and when to call the processing functions prepared by the server program is handled by that set of databases. In short, the reactor will notify you when an I/O event occurs, so you don't have to keep your guard until the event occurs. Let's move on to other things.
I/O concurrency mode-reactor Mode
