Two IO multiplexing schemes: Reactor and Proactor
In general, the I/O multiplexing mechanism requires an event sharing device (event demultiplexor [ 1 , 3 ]). The function of the event sharing device is to distribute those read and write event sources to the handlers of each read and write event, just like express delivery The person shouted downstairs: Whoever gave it something, come get it. Developers need to register interested events in the sharer at the beginning, and provide corresponding handlers (event handlers), or callback functions; the event sharer will distribute the requested events to these handlers or Callback.
The two modes involving event sharers are called: Reactor and Proactor [ 1 ]. Reactor mode is based on synchronous I/O, while Proactor mode is related to asynchronous I/O. In Reactor mode, the event separator waits When an event or an application or operation status occurs (such as a file descriptor readable and writable, or a socket readable and writable), the event detacher will pass the event to the pre-registered event handler or callback function, and then To do the actual read and write operations.
In the Proactor mode, the event handler (or initiated by the event separator) directly initiates an asynchronous read and write operation (equivalent to a request), and the actual work is done by the operating system. When initiating, the parameters that need to be provided include the buffer area used to store the read data, the size of the read data, or the buffer area used to store the outgoing data, and the callback function after the request is completed. When the event separator learns the request, it silently waits for the completion of the request, and then forwards the completion event to the corresponding event handler or callback. For example, on Windows, the event handler delivers an asynchronous IO operation (known as overlapped technology), and the event separator completes the IOCompletion event [ 1 ]. The typical implementation of this asynchronous mode is based on the asynchronous API at the bottom of the operating system. , So we can call it "system level" or "real sense" asynchronous, because the specific reading and writing are done by the operating system.
Give another example to better understand the difference between the two modes of Reactor and Proactor. Here we only focus on the read operation, because the write operation is similar. Here is what Reactor does:
- An event handler declares that it is interested in read events on a certain socket;
- The event separator waits for this event to happen;
- When an event occurs, the event separator is awakened, which is responsible for notifying the previous event handler;
- The event handler receives the message, and then reads the data on that socket. If necessary, it again declares that it is interested in reading events on this socket and repeats the above steps;
Let's take a look at how the real asynchronous mode Proactor is done:
- The event handler directly sends a write operation (of course, the operating system must support this asynchronous operation). At this time, the event handler does not care about the read event at all, it just sends such a request, and what it dreams of is the completion event of the write operation . The processor is very awkward, and it doesn't matter what the specific thing is when you send an order, just waiting for someone (system) to help him get it done and give him a reply.
- The event separator waits for the completion of this read event (compared to the difference with Reactor);
- While the event separator silently waits for the completion of the matter to arrive, the operating system is already working on the side. It reads data from the target, puts it into the user-provided buffer area, and finally informs the event separator that I am finished;
- The event sharer notifies the previous event handler: The thing you ordered is done;
- The event handler will find that the data he wants to read has been placed in the buffer area he provided, and he can handle it whatever he wants. If necessary, the event handler also initiates another write operation as before, just like the steps above.