Muduo Library Source Analysis (i) reactor mode

I. Introduction to the reactor model

Reactor interpretation of "reactor" is an event-driven mechanism. Unlike a normal function call, the application does not actively invoke an API to complete processing, but instead, reactor the event-handling process, the application needs to provide the appropriate interface and register it on the reactor, if the corresponding time occurs, Reactor will actively invoke the application-registered interfaces, which are also called "Callback functions."

Two. Implementation of Moduo Library reactor model

Muduo mainly through 3 classes to achieve Reactor mode: Eventloop,channel,poller.

1. EventLoop

The event loop. The Moduo threading model is one loop per thread, that is, there can be only a single EventLoop object for each of the threads. The life cycle of a EventLoop object is usually as long as the thread it belongs to.

Data members:

Const pid_t threadid_; Save current EventLoop owning thread ID

Boost::scoped_ptr Poller_; Realize I/O multiplexing boost::scoped_ptr timerqueue_;

int wakeupfd_;

Boost::scoped_ptr Wakeupchannel_; For handling readable events on wakeupfd_, distributing events to Handlread () channellist Activechannels_; Channel channel* currentactivechannel_ with event readiness;

Mutexlock mutex_; Pendingfunctors_ back to other threads, so need to lock std::vectorpendingfunctors_;

Main function function:

Loop (), in which the following procedure is iterated: Call Poller::p oll (), which obtains a vector<channel*>activechannels_ set of ready events for the call, and then traverses the container. Executes each channel channel::handleevent () completes the corresponding Ready event callback, and finally executes the Pendingfunctors_ queued function. The first cycle is the completion of a reactor mode.

Runinloop (Boost::function<void () >), to implement user-specified task callback, if eventloop subordinate thread calls Eventloop::runinloop () EventLoop immediately execute; Execute Eventloop::queueinloop (boost::function<void () > Add the task to the queue (thread transfer) if the other thread calls. How does the EventLoop get the facts of a mission? EVENTFD enables the communication between threads by adding task T to eventloop::vector<boost::function<void () > >, and then through EventLoop:: Wakeup () writes to EVENTFD a INT,EVENTFD callback function Eventloop::handleread () reads the int, which is equivalent to the EventLoop being awakened, in which the queue performs the stacked task at the loop. Here the use of channel management Eventfd,poller listening EVENTFD embodies the EVENTFD can unify the advantages of the event source.

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/cplus/

Queueinloop (functor& CB), put the CB into the queue and, if necessary, wake IO threads. There are two situations that require a wake-up IO thread, the 1 call to Queueinloop () is not an IO thread, and 2 calls Queueinloop () is an IO thread, and pengding functor is being invoked at this time.

2. Channel

Event Distributor. Each channel belongs to only one eventloop, each channel is responsible for only one file descriptor for IO event distribution, but it does not have FD.

Data members:

int Fd_ file descriptor,

int Events_ File Descriptor Registration event,

The Ready event for the int revents_ file descriptor, set by Poller::p Oll

Readcallback_,writecallback ... Various event callbacks, which are registered in the constructor that owns the channel class, such as Tcpconnction in the constructor Tcpconnection::handlread () to Channel::readcallback

Main function function:

Setcallback () series function that accepts the corresponding event callback function for the class to which the channel belongs

Enablereading (), update (), when an FD wants to register a readable event, first through Channel::enablereading ()-->channel::update (this)->eventloop: : The Updatechannel (Channel)->poller::updatechannel (channel*) call chain registers or modifies a registration event to a listening event table that is called by the poll system.

Handleevent (), channel as the event distributor whose core structure is channel::handleevent (), the function calls Channel::handleeventwithguard (), which is based on channel:: The Revents value distribution invokes the appropriate event callback.

3. Poller

The Poller is an IO multiplexing package that encapsulates poll and Epoll. Poller is an indirect member of the EventLoop that is invoked only by the EventLoop that owns the poller in IO threads. The life period is equal to the eventloop.

Data members:

Vector POLLFDS_ Event structure array is used for the first parameter of poll;

Map<int,channel*> Channels_ is used for mapping file descriptors FD to channel to quickly find the corresponding channel

Main function function:

Updatechannel (channel*) is used to register events that are passed in Channel care to Poller.

Poll (int timeoutms,vector<channel*> Activechannels) calls poll listens for events collection, channel that the Ready event belongs to Fillactivechannels () Join in the Activechannels_.

Other classes

Eventloopthread: Starts a thread to execute a eventloop whose semantics coincide with "one loop per thread". Note that the mutex and condition variables are used here because thread a creates a Eventloopthread object after a running EventLoop thread has been created and can be passed Eventloopthread::startloop () Gets the EventLoop object, but an error occurs if the EventLoop thread has not yet been created. So the condititon.notify () notification thread A is executed after the creation of the EventLoop, and the call to Condition.wai () waits when thread A calls Eventloopthread::startloop (). This ensures that a completed eventloop is obtained. After all, thread A creates a eventloop thread, and a may also invoke EventLoop to perform some task callbacks.

Author: cnblogs nicganon</