I/O multiplexing, select and reactor modes

I/O multiplexing, select and reactor modes, the relationship between the respective concepts, and, most importantly, their strengths, and why they have such advantages over their peers. This is the original starting point for writing this text. I/O multiplexing

I/O multiplexing belongs to one of the I/O models:
1. Blocking I/O:

2. Non-blocking I/O:

3. I/O multiplexing model

4. Signal-driven I/O model

5. Asynchronous I/O model

The comparisons between the above models are as follows:
Select

A select is a function in C language that, in relation to a blocking program such as Connect, accept, recv, or recvfrom, can accomplish non-blocking (the so-called non-blocking method Non-block, with a select). is when a process or thread executes this function without having to wait for the event to occur, once the execution returns, the function is reflected in a different return value, if the event occurs in the same way as blocking, and if the event does not occur, a code is returned to tell the event not to occur, and the process or thread continues to execute. So it's a more efficient way to work with programs that monitor the changes in the file descriptor that we need to monitor--read or write or exception.

The change in the monitoring (multiple) file descriptor is the way select implements I/O multiplexing. Any one that is readable, writable, or unexpected can awaken the current process of the Select function to continue working, reducing the time that the process is blocked.

Therefore, the main business of select is to set up listening to one or more objects, and to centralize all blocking events, once any of them are available, that is, to wake up the process, and multiple I/O that should have been performed on their respective processes will be reused in a single process to achieve I/O reuse.
Reactor Mode Intent

In an event-driven application, the service Request separation (Demultiplex) and Dispatch (dispatch) of one or more customers are given to the application. problem

In the event-driven applications such as distributed systems, especially servers, these requests are eventually processed in a serialized manner, but must be prepared to handle multiple simultaneous service requests at all times. In practical applications, these requests are always represented by an event, such as connector, READ, write, and so on. Before processing these service requests in an orderly manner, the application must first detach and schedule these simultaneous events. In order to effectively solve this problem, we need to do the following 4 aspects: In order to improve the system's scalability and response time, the application can not be blocked for a long time on an event source and stop processing other events, which can severely reduce the responsiveness to the client. To improve throughput, any unnecessary context switches, synchronizations, and data movement between CPUs are avoided. The introduction of new services or the improvement of existing services to the existing event separation and scheduling mechanism to bring the smallest possible impact. A large number of application code needs to be hidden behind complex multithreading and synchronization mechanisms. Solving Method

Waits for the arrival of an event on one or more event sources, for example, a socket descriptor that is already connected is an event source. The separation and scheduling of events is integrated into the services that handle it, while separation and scheduling mechanisms are separated from the processing of specific events by the application, which means that the separation and scheduling mechanisms are independent of specific applications.

Specifically, each service provided by each application has a separate event handler corresponding to it. The event handler handles a specific type of event from the source of the event. Each event handler is registered in advance in the reactor manager. The reactor manager waits for the occurrence of an event in one or more event sources using the synchronization event separator. When the event occurs, the synchronization event separator notifies the reactor manager and finally completes the requested service by the reactor manager scheduling and event handlers associated with the event. structure

In the reactor model, there are 5 key players. Descriptor (HANDLE): provided by the operating system to identify each event, such as the socket descriptor, file descriptor, and so on. In Linux, it is represented by an integer. Events can come from outside, such as connection requests from clients, data, and so on. Events can also come from within, such as timer events. Sync Event Separator (demultiplexer): is a function that waits for one or more events to occur. The caller is blocked until an event occurs on the descriptor set that separates the separator. The Select function of Linux is a separator that is often used. Event handler Interface (handler): an interface consisting of one or more template functions. These template functions describe an application-related action on an event. Specific event handler: is the implementation of the event handler interface. It implements a service provided by the application. Each specific event handler sums a descriptor relative. It uses descriptors to identify events and identify the services provided by the application.

Reactor Manager (Reactor): Defines interfaces for application control event scheduling and application registration, removal of event handlers, and associated descriptors. It is the scheduling core of the event handler. The reactor manager uses the synchronization event separator to wait for the event to occur. Once the event occurs, the reactor manager detaches each event, then dispatches the event handler, and finally invokes the relevant template function to handle the event.

Through the above analysis, we note that the reactor manager is responsible for waiting for events, detaching events, and scheduling events, rather than applications. In fact, the reactor manager is not invoked by a specific event handler, but instead the manager dispatches a specific event handler, which is handled by the event handler for the event that occurs. This is similar to the Hollywood principle of "reverse control." The only thing the application does is implement a specific event handler and then register it in the reactor manager. The next work is done by the manager. The interrelationships of these participants are shown in the following illustration.

I/O multiplexing, select and reactor

Select is a component in the reactor design pattern, or it is the most core component, providing the entire module with the ability to register events and listen to events, from another point of view is the distribution of events, he will be caused by the blocking waiting to focus on their own this place for coordinated treatment, Enables efficient I/O reuse in a single process.

As a result, the reactor model provides a new way for the server to handle multiple requests-we don't have to rely on multiple threads to handle it, and the overhead of frequent switching between multithreading is huge. In contrast, select operations, which appear to have done a lot of pointless work on the surface, will bring better results in concrete applications. and its specific advantages can refer to the above "reactor mode" in the "Problem" column.