Linus在周六关闭了linux kernel这一轮的合并窗口，并2.6.22的第一个候选版本。
这次的动作相当大，更改了近7000个文件，涉及体系结构、驱动、文件系统、网络、安全、构建脚本、重组、清理...你能想到的几乎都涉及到了。更为详细的信息请参阅其短格式的更改和长格式的更改。
如此冗长的日志我是没有精力详细读完的，也更加佩服每天都埋在补丁堆里的Linus了。众多更改中，只有两项比较吸引我的眼球：和。程序设计中的内存管理我关注也有一段时间了，关于它我会另辟文章总结。至于后者，我以前也有
文章简单讨论过，只是没有想到它会这么快进入官方内核，甚至当时我都不看好它，这次内核选它而不是接口，也许是出于对“功能正交”这个设计原则的考虑，不知道kevent以后还有没有机会进入官方内核！
事件的文件描述符化除了上面提到的内核实现，库中其实早就存在另一套用户空间的实现方法：
- 定时器：将所有超时事件按照时间的前后组织成一个红黑树，每次抽取最近到期的超时事件，将其与当前时间的间隔作为超时参数传递给select/poll/epoll类函数，当select/poll/epoll由于超时返回，或者是时间自然到期或超时，相应的超时任务就将被调度执行。
- 信号：libevent接管系统的信号处理，在它提供的信号处理函数中，首先将相应信号的计数器值增加，然后通过将一个字符‘a’写入预先创建的UNIX域套接字对的一端来唤醒正在UNIX域套接字对的另一段等待的select/poll/epoll，随后libevent将在主循环中调用用户为这个信号注册的信号处理函数。
不难发现，在libevent的信号实现中，UNIX域套接字对充当了通信通道，在唤醒主主循环的过程中起到了至关重要的作用，如此技巧不能不让人感叹，其它的一些事件是不是也能如法炮制呢？比如inotify和aio等，必要的时候还可以引入帮助线程。
按照以上的分析，似乎没有哪种事件不可以在用户空间实现统一接口，如果这样，还真的有必要把类似机制放进内核么？性能？
阅读(1395) | 评论(0) | 转发(0) |
