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阻塞进程,(功能的分离)