linux poll使用定时中断,中断/轮询；select/poll/epoll；脚本tick/事件

接触到的技术多了，会发现很多异曲同工的东西。

最近在看Linux内核，看到中断和异常这块，想起来了以前体系结构课上讲到的关于轮询和中断的概念。二者都是操作系统和硬件交互的方式。开始时是轮询的方法，内核(通常是驱动)需要自己去轮询硬件看硬件是否有事件，如果有则处理，没有则继续轮询，直到被操作系统挂起。这显然是很低效的。于是有了中断这种更好的方案。

但我认为中断本质上仍然是轮询，只不过是把轮询操作放在了硬件层，提高了轮询的效率。中断是如何实现的？通过IRQ(Interrup ReQuest)，IRQ其实就是一个硬件的轮询系统，它连接了所有的硬件，每个硬件分配一个独立的IRQ编号。硬件有消息就会放在它自己的IRQ里。然后CPU会在每个指令周期结束时查看IRQ里是否有消息，如果有就触发中断给内核去处理。

这就让我联想到了IO复用epoll。以前的poll/select之所以低效是因为要在应用层遍历所有socket的状态。epoll只不过是把这个过程交给内核，内核只把有新输入输出的socket fd返回给应用层，应用层不再需要遍历所有socket fd，从而提高了效率。

再比如游戏里，在脚本层写tick很影响效率。于是把tick的逻辑尽量放在引擎层，然后利用事件与脚本交互。例如要在主角播放攻击动画的第n帧判定是否击中，简单的做法是在脚本里每帧去检查，然后到第n帧的时候执行操作。更高效的做法是让引擎去做每帧检查的任务，脚本层只需要给引擎注册一个回调，当播放到第n帧的时候，引擎调用回调即可。但本质上，仍然是轮询，只不过把轮询向下移动了一层，在执行更快速的地方轮询。

总结一下就是：当主体需要了解客体的状态，而主体并不能直接接收到客体的消息时，主体的轮询是无法避免的。主体所能做的是尽可能把轮询的操作放在更底层，这样才可以提高效率。