io多路复用

select和epol的用法

代码：

初始化并清空
fd_set readfds;
FD_ZERO(&readfds);
阻塞等待文件描述符准备完毕
while(1)
{
	添加
	FD_SET(0,&readfds)
	FD_SET(sockfd,&readfds)
	if (select(sockfd+1, &readfds,NULL,NULL,NULL)<0)
	{
		errlog
	}
	if (FD_ISSET(0,&readfds))
	{
		fget
	}
	if (FD_ISSET(sockfd,&readfds))
	{
		accpet();//接受网络信息
	}
}

当前集合只剩下准备就绪的
所以，由此可见，select的操作只是把轮训，等待并且查看文件句柄是否ready的动作交给了操作系统，然后每次由select操作自己去轮训，判断，多个不同线程的io操作可以都注册给select，这样就叫做了复用。

而epool操作则比select更为高效：原因有两个
1、epool操作由用户态和内核态共享一部分内存，减少了一次用户态到内核态拷贝的时间
2、epol采用注册，事件回调的策略，免去了无效轮询的时间。
实际上，这两种操作也还都是同步io，因为就算是epol，等待的io也还是不能走，需要等事件通知之后，再将内存拷贝回用户态，然后再执行后续操作。
真正的异步io几乎不可能，因为所有的操作几乎都是依赖io结果，不可能抛开结果，向下执行，只能说这个io线程可以不挂起，还在运行。就像9000中的fce线程一样，收到回调，就把结果放在一个事件中，再放回状态机中重新运行。

redis的io多路复用怎么理解

redis服务器端采用单线程处理多个client端发过来的请求，用到的就是io多路复用技术。怎么理解呢？上述来看io多路复用貌似都是io请求同步等响应啊，而redis服务器本身就是处理io请求的啊。
我觉得可以这么理解，只是采用了io多路复用的思想和框架，比如使用select函数，一直监听readable，wirteablt的套接字，直到ready就用相应的处理函数处理。表面上看是在等io处理的结果，实际上就是在等一个事件。用单线程等一个事件，io多路复用的初始模型是多个文件句柄由一个线程等待，然后继续做。redis则是单线程等待事件，等到了，由事件处理器去做，然后再等事件，再处理。