config.h-config.cpp详解

config.h定义四种组合方式切换“ET LT”
listenfd触发模式 ET LT
connfd触发模式 ET LT

LT是电平触发、ET是边缘触发。
level-triggered VS edge-triggered
电平触发：只要有就能触发。
边缘触发：从无到有才能触发。

以socket为例
可读：有数据
不可读:没有数据
可写：有空间可写
不可写：无空间可写

LT 水平 电平 level
只要socket有没读完的数据，就会一直触发EPOLLIN
只要socket可以写，EPOLLOUT就可以一直触发
这种方式，读数据简单（因为不担心丢）
但是写数据 必须移除检测可写 不然一直无意义触发

ET 边缘 edge
读事件必须从无到有，才可以触发EPOLLIN
必须是写缓冲区从满到不满，才可以触发EPOLLOUT
清爽 状态变化才会通知 但是但是但是：必须读事件读干净

阻塞IO：读一个阻塞的fd时，如果没有数据可读，就会一直卡在调用函数上，一直等到可读。

非阻塞IO:读一个fd，不管他可不可以读写，都会立刻返回，返回失败会设置errno码通知，而不是卡着不动

server有两个文件描述符：
listenfd：创建socket就会得到
clientfd：调用accept就会得到
client有一个文件描述符：
connfd：客户端创建得到的，主动发起对server连接

总结

LT会一直触发EPOLLOUT 有数据来就EPOLLIN
ET会建立连接之后触发一次EPOLLOUT 收到数据触发一次IN

所以LT不适合EPOLLOUT 因为一直触发
ET不是和EPOLLIN 因为没发完 下一次发不了

#ifndef CONFIG_H
#define CONFIG_H
#include "webserver.h"
using namespace std;

class Config
{
public:
    Config();
    ~Config(){};
    void parse_arg(int argc, char*argv[]);

    //端口号
    int PORT;
    
    //日志写入方式
    int LOGWrite;

    //触发组合模式
    int TRIGMode;

    //listenfd触发模式
    int LISTENTrigmode;

    //connfd触发模式
    int CONNTrigmode;

    //优雅关闭链接
    int OPT_LINGER;

    //数据库连接池数量
    int sql_num;

    //线程池内的线程数量
    int thread_num;

    //是否关闭日志
    int close_log;

    //并发模型选择
    int actor_model;
};

#endif

config.cpp
默认listenfd和connfd都是LT模式（电平 水平 level）

文件描述符fd：非负整数，是个索引。
打开文件，内核给进程返回一个fd
后续的读写 就靠fd标识这个文件，这是个参数，是个索引。
（例子是能打开4864个fd（就是打开4864个文件））

EPOLL：红黑树+回调机制
不管节点数目是多少，效率都是一条直线（有回调的好处）
而select和poll都是需要数据拷贝
epoll可以直接得到就绪的文件描述符（用户体验）
没有最大文件描述符的限制

对于要监听的socket文件描述符就是：listenfd；
对于accept（）返回的（就是要读写的）时：connfd;

#include "config.h"

Config::Config(){
    //端口号,默认9006
    PORT = 9006;

    //日志写入方式，默认同步
    LOGWrite = 0;

    //触发组合模式,默认listenfd LT + connfd LT
    TRIGMode = 0;

    //listenfd触发模式，默认LT
    LISTENTrigmode = 0;

    //connfd触发模式，默认LT
    CONNTrigmode = 0;

    //优雅关闭链接，默认不使用
    OPT_LINGER = 0;

    //数据库连接池数量,默认8
    sql_num = 8;

    //线程池内的线程数量,默认8
    thread_num = 8;

    //关闭日志,默认不关闭
    close_log = 0;

    //并发模型,默认是proactor
    actor_model = 0;
}

void Config::parse_arg(int argc, char*argv[]){
    int opt;
    const char *str = "p:l:m:o:s:t:c:a:";
    while ((opt = getopt(argc, argv, str)) != -1)
    {
        switch (opt)
        {
        case 'p':
        {
            PORT = atoi(optarg);
            break;
        }
        case 'l':
        {
            LOGWrite = atoi(optarg);
            break;
        }
        case 'm':
        {
            TRIGMode = atoi(optarg);
            break;
        }
        case 'o':
        {
            OPT_LINGER = atoi(optarg);
            break;
        }
        case 's':
        {
            sql_num = atoi(optarg);
            break;
        }
        case 't':
        {
            thread_num = atoi(optarg);
            break;
        }
        case 'c':
        {
            close_log = atoi(optarg);
            break;
        }
        case 'a':
        {
            actor_model = atoi(optarg);
            break;
        }
        default:
            break;
        }
    }
}

代码显示：池内线程为8，可以改为实际的线程数。
触发组合方式TRIGMode默认0，可以改为1，QPS增大十倍。

epoll的本质是：通过硬件传输，网卡接收的数据存放到RAM中，操作系统就可以进行读取了。（通过中断信号完成）

为什么进程的阻塞不占用cpu：因为一个进程创建socket时候，os会给他创建一个由文件系统管理的socket对象，包括发送缓冲区、接收缓冲区、等待队列等成员。而执行到recv时，os会直接把这个工作队列的进程移到socket的等待队列，所以这个既会被阻塞（等待接收），又不影响工作队列（不影响cpu）

那么：上述只是满足了一个socket，多个怎么办？

select就是来解决的（但不完美）：一个进程同时监视多个socket。(把这个进程加到多个sock的等待队列中）。这个进程一旦被唤醒，呢么就遍历一下socket列表就知道是谁了。

问题在于：select把维护等待队列—请求进程 合二为一了
而epoll分开了。用epoll_ctl维护等待队列，用epoll_wait阻塞进程，（功能的分离）