一个服务器程序，一般都需要处理三类事件：IO事件、定时事件、信号。而为了方便处理，我们需要统一事件源，比如使用IO复用来管理所有事件。其次，为了实现跨平台，我们需要提供一个平台无关的统一接口，与平台相关的实现在内部完成。比如对于IO复用，linux下有epoll，windows等其它平台有select，这里我们就可以统一封装，对外提供一致的接口。一个事件管理接口，还应该是支持多线程的，本节学习下ZLToolKit中的事件管理工具：EventPoller。支持定时事件、IO事件处理，通过内置的管道事件，也可以实现多线程执行任务的负载均衡。

一、概述

EventPoller类按照本人的理解，接口大致分为4类：内部管道事件、定时器事件、用户事件(用户可以自己管理的事件，可以是管道、网络socket等)以及线程相关的接口。

EventPoller的事件处理模式为Reactor模式，每一个事件都有其对应的回调，在事件触发后，该回调被调用。

EventPoller的事件管理一般在单独的线程中进行，这可以通过runLoop函数确定。该接口的第一个参数可以设置是否为阻塞的，非阻塞状态下，会创建一个线程，后续的事件监听在线程中进行。linux系统下，事件监听通过epoll管理，非linux平台，通过select管理。

该类虽然是一个单例类(构造函数私有)，但是由于其将EventPollerPool作为友元类，所以，使用时，我们一般不直接实例化该类对象，而是通过其友元类EventPollerPool来间接使用。在EventPollerPool中，会根据用户指定的size或者CPU核心数创建多个EventPoller的实例，后续使用时，根据特定条件选择其中一个来调用(比如选择负载最轻的)。

对于EventPollerPool的学习，可以参见《ZLToolKit源码学习笔记》（11）线程模块之工作线程池WorkThreadPool，两者类似。

二、功能分析

2.1、内部管道事件

内部管道事件用于用户工作线程和事件监听线程之间的通信。事件监听线程中，监听了管道的读端，用户工作线程中，使用管道的写端。

基于该管道事件，实现了一个任务队列，可以在该线程中异步的执行任务。_list_task用于存储和管道关联的任务，async_l负责将任务加入到_list_task中，然后向管道中写入数据，触发其读事件，runLoop中监听到该事件后，调用onPipeEvent来执行并清除_list_task中的任务。

2.1.1、构造函数

EventPoller::EventPoller(ThreadPool::Priority priority ) {
    _priority = priority;
    SockUtil::setNoBlocked(_pipe.readFD());
    SockUtil::setNoBlocked(_pipe.writeFD());

#if defined(HAS_EPOLL)
    _epoll_fd = epoll_create(EPOLL_SIZE);
    if (_epoll_fd == -1) {
        throw runtime_error(StrPrinter << "创建epoll文件描述符失败:" << get_uv_errmsg());
    }
    SockUtil::setCloExec(_epoll_fd);
#endif //HAS_EPOLL
    _logger = Logger::Instance().shared_from_this();
    _loop_thread_id = this_thread::get_id();

    //添加内部管道事件
    if (addEvent(_pipe.readFD(), Event_Read, [this](int event) { onPipeEvent(); }) == -1) {
        throw std::runtime_error("epoll添加管道失败");
    }
}

可以看到，管道的读端fd被添加到事件列表中，当管道读事件被触发时，会执行onPipeEvent函数。

2.1.2、onPipeEvent-管道读事件回调

inline void EventPoller::onPipeEvent() {
    TimeTicker();
    char buf[1024];
    int err = 0;
    do {
        if (_pipe.read(buf, sizeof(buf)) > 0) {
            continue;
        }
        err = get_uv_error(true);
    } while (err != UV_EAGAIN);

    decltype(_list_task) _list_swap;
    {
        lock_guard<mutex> lck(_mtx_task);
        _list_swap.swap(_list_task);
    }

    _list_swap.for_each([&](const Task::Ptr &task) {
        try {
            (*task)();
        } catch (ExitException &) {
            _exit_flag = true;
        } catch (std::exception &ex) {
            ErrorL << "EventPoller执行异步任务捕获到异常:" << ex.what();
        }
    });
}

该接口在管道的读事件发生后被调用，执行_list_task中的任务。首先读取管道中的数据，然后交换_list_task，即清空其中任务。最后以此执行所有任务。

2.1.3、async_l-添加需要在事件监听线程中执行的任务

Task::Ptr EventPoller::async_l(TaskIn task,bool may_sync, bool first) {
    TimeTicker();
    if (may_sync && isCurrentThread()) {
        task();
        return nullptr;
    }

    auto ret = std::make_shared<Task>(std::move(task));
    {
        lock_guard<mutex> lck(_mtx_task);
        if (first) {
            _list_task.emplace_front(ret);
        } else {
            _list_task.emplace_back(ret);
        }
    }
    //写数据到管道,唤醒主线程
    _pipe.write("", 1);
    return ret;
}

异步执行的情况下，将任务添加到_list_task中，然后通过向管道中写数据来触发读事件，runLoop事件监听线程中调用onPipeEvent来执行任务。

2.2、定时事件

该部分已经在定时器一节中学习过，可参见《ZLToolKit源码学习笔记》（14）事件轮询模块之定时器。

2.3、用户事件

用户可以通过addEvent、delEvent、modifyEvent三个接口，将自己关心的事件让EventPoller来管理。所有被管理的事件都存放在_event_map中。

unordered_map<int, Poll_Record::Ptr> _event_map;

2.3.1、addEvent-添加事件监听

int EventPoller::addEvent(int fd, int event, PollEventCB cb) {
    TimeTicker();
    if (!cb) {
        WarnL << "PollEventCB 为空!";
        return -1;
    }

    if (isCurrentThread()) {
#if defined(HAS_EPOLL)
        struct epoll_event ev = {0};
        ev.events = (toEpoll(event)) | EPOLLEXCLUSIVE;
        ev.data.fd = fd;
        int ret = epoll_ctl(_epoll_fd, EPOLL_CTL_ADD, fd, &ev);
        if (ret == 0) {
            _event_map.emplace(fd, std::make_shared<PollEventCB>(std::move(cb)));
        }
        return ret;
#else
#ifndef _WIN32
        //win32平台，socket套接字不等于文件描述符，所以可能不适用这个限制
        if (fd >= FD_SETSIZE || _event_map.size() >= FD_SETSIZE) {
            WarnL << "select最多监听" << FD_SETSIZE << "个文件描述符";
            return -1;
        }
#endif
        Poll_Record::Ptr record(new Poll_Record);
        record->event = event;
        record->callBack = std::move(cb);
        _event_map.emplace(fd, record);
        return 0;
#endif //HAS_EPOLL
    }

    async([this, fd, event, cb]() {
        addEvent(fd, event, std::move(const_cast<PollEventCB &>(cb)));
    });
    return 0;
}

将事件注册到epoll或者select中管理。注意看函数最后的async调用（前边的if (isCurrentThread())判断了是否是事件监听线程），说明该接口实际的操作不是在用户工作线程中执行的，而是转移到了事件监听线程中执行，避免了多线程操作epoll或者select。

每一个事件都有其对应的回调，在事件触发后，该回调被调用。

对于epoll，直接调用epoll系列api进行操作，对于select，由于每次都需要重新添加要监听的事件，所以这里仅将事件放入_event_map中，添加到select的操作在runLoop中执行。节选runLoop中相关代码如下：

set_read.fdZero();
set_write.fdZero();
set_err.fdZero();
max_fd = 0;
for (auto &pr : _event_map) {
    if (pr.first > max_fd) {
        max_fd = pr.first;
    }
    if (pr.second->event & Event_Read) {
        set_read.fdSet(pr.first);//监听管道可读事件
    }
    if (pr.second->event & Event_Write) {
        set_write.fdSet(pr.first);//监听管道可写事件
    }
    if (pr.second->event & Event_Error) {
        set_err.fdSet(pr.first);//监听管道错误事件
    }
}

startSleep();//用于统计当前线程负载情况
ret = zl_select(max_fd + 1, &set_read, &set_write, &set_err, minDelay ? &tv : NULL);
sleepWakeUp();//用于统计当前线程负载情况

delEvent、modifyEvent和addEvent接口类似，不再赘述。