Typical server model

Ibevent:

Reactor Reactor Model:

Key parts:

1) Event Source
Linux is a file descriptor, Windows is a socket or handle, here is known as a "handle set", the program on the specified handle register the event of interest, such as I/O events.

2) Event demultiplexer--events Multi-channel collection and distribution mechanism (in fact, epoll, etc., directly used in reactor)
The I/O multiplexing mechanisms provided by the operating system, such as SELECT and Epoll.
The program first registers its concerned handle (event source) and its events on the event demultiplexer;
When an event arrives, the event Demultiplexer notifies "that one or more handles are ready in the registered handle set";
Once the program is notified, the event can be processed in a non-blocking situation.
Corresponding to the libevent, is still select, poll, Epoll, etc., but libevent using the structure of eventop encapsulation, with a unified interface to support these I/O multiplexing mechanism, to the external hiding the underlying system mechanism.

3) reactor--reactor
Reactor is an event management interface that internally uses event demultiplexer to register, unregister, and run an event loop that invokes the callback function that registers the event to handle the event when an event enters the ready state.
Corresponding to the libevent, is the event_base structure.
A typical reactor declaration method

class reactor{public:    intintevent);     int int Event );     void handle_events (timeval *PTV);     //  ...};

View Code

4) event handler,(note that the event handler is a whole, the whole can be registered, bound together with the event, in other words, the event handler class, which claims to be interested in the event (so-called event, read-write thing, etc.) . handler--
The event handler provides a set of interfaces, each of which corresponds to a type of event that reactor is invoked when the corresponding event occurs and performs the corresponding event handling. Typically, it binds a valid handle.
Corresponds to the libevent, which is the event structure body.
Here are two typical event handler class declarations, each with their pros and cons.

classevent_handler{ Public:    Virtual voidHandle_read () =0; Virtual voidHandle_write () =0; Virtual voidHandle_timeout () =0; Virtual voidHandle_close () =0; VirtualHANDLE get_handle () =0; // ...};classevent_handler{ Public:    //events maybe read/write/timeout/close. etc    Virtual voidHandle_events (intevents) =0; VirtualHANDLE get_handle () =0; // ...};

View Code

And then in the reactor loop Wait_epoll, which uses the Demultiplexer function, while the reactor hanle_events is (when the event source is ready, Callback pre-registered time-processing function) by transferring the function in the demultiplexer, due to the readiness of the FD, you can get the event ready for him, according to the relationship between handle and event handlers, through the map store, so that you can get registered event handler function, Then, depending on the event type (write or read), the corresponding function in the event-handling class is called

Each event-handling class corresponds to a handle, but an identical handle can correspond to multiple event-handling classes (at different times). This handle has aceept generated.

The

int Reactorimplementation::registerhandler (EventHandler * handler, event_t evt)    //parameters are event-handling classes and events, However, the GetHandle () function in the event-handling class gets the handle event source corresponding to the event-handling class. Then the correspondence between the handle and the event-handling classes is then     {                      &NBS P                          ,         &NB Sp                          ,         &NB Sp                      //Map
handle_t handle = Handler->geth Andle ();
std::map if (it = = M_handlers.end ())
{
M_handlers[handle] = handler;
}
return m_demultiplexer->requestevent (handle, EVT);
}

map

Each FD has a corresponding event, if the corresponding FD above the event is ready to return to FD, and because of the time of registration, the event is corresponding to the event processing class, the event processing class claims to be interested in the event. Therefore, it is possible to find the corresponding Ready event based on FD and then callback the event handler class. The parameters of the function that registers the event are the FD type and the event-handling class type.

Typical server model