With the advent of IO multiplexing technology, there are many event processing modes. The synchronous I/O model is typically implemented by the reactor pattern, while the asynchronous I/O model is implemented by the proactor pattern.
As shown above, the reactor mode is also called a reactor or reactor, the processor that implements the registration descriptor (HANDLE) and the event (EventHandler), and when an event occurs, the event Reator Demultiplexer) responds by invoking the event-specific handler function (Concreteeventhandler::handle_event ()).
The typical boot process for Reator mode is as follows:
- Create reactor
- Registering the Event Processor (Reactor::register_handler ())
- Invoke event multiplexer into infinite event loop (reacor:handle_events)
- When the operating system notifies a descriptor that the state is ready, the event multiplexer finds and invokes the event handler registered by this descriptor.
The reactor model has been widely used, and the famous open source event library Libevent, Libev, and LIBUV are all using reactor mode.
Advantages of the reactor mode:
- The implementation is relatively simple, and it is efficient for processing scenes with short time.
- The operating system can wait on multiple event sources and avoids the performance overhead and programming complexities associated with multithreaded programming;
- The serialization of events is transparent to the application and can be executed synchronously without the need of locking;
- Transaction separation: Separates application-independent, multi-path decomposition and allocation mechanisms from application-related callback functions.
Disadvantages of the reactor model:
Reactor processing time-consuming operations, such as file I/O, can cause blocking of event distribution and affect the handling of subsequent events.
Therefore, it involves file I/O related operations and requires the use of asynchronous I/O, which means better use of the Proactor mode.
Two efficient event-handling models: Reactor mode and Proactor mode