基于线程还是基于事件

这个题是盗用上的""，这篇文章又引发了一场争论，结论当然还是各有所长，又是一个“无用”的争论...

个人认为事件驱动的编程模型比线程/进程模型更加“底层”，这当然又是一把双刃剑（怎么到处都是哲学？），给你提供了无限机会的同时，也让你承担了更多的风险。相比之下，线程/进程的编程模型是“牺牲”了些优化空间，却带来了更多的安全性和便利性。他们之间的取舍还是要具体问题具体分析的，似乎又是一通废话...

争论的引子是来异步io的实现方式：

1. 事件回调和回调不可用时的重试方式[]：这是目前内核中的异步IO实现。不过他只实现了文件的O_DIRECT方式读写，对于文件的缓冲读写和其他比如socket的异步读写还没能实现。倒是存在了很长时间，就是一直未能进入官方的内核，猜测可能因为有与之有异曲同工之妙的select/poll/epoll机制的存在，致使对此功能的需求一直不是很强劲。那为什么文件部分进入了官方内核？因为select类调用不支持文件，或者说那种接口不适合文件，所以才有了异步IO作为补充。
2. 基于线程/进程的实现方式[]：这段时间被广泛讨论的就是这个了，其实目前内核异步io的实现者也早就讨论过这种方式[]，并且glibc也有用户空间实现的异步IO：。这个idea唯一新的地方可能就是：只有当调用不能同步完成的时候才启动一个内核线程。至于它所提到的能够比较容易的实现所有IO的异步，我想大家对于此点都是心知肚明的，没啥新鲜感。

被纠缠进来的还有力图统一事件驱动接口的，其实人家想要解决的主要问题本来与这个无关的，被扯进来也是沾了event的光，好象有些无辜，hoho！

最后，还是Linus打“圆场”[]，其言辞颇有邓的“猫论”的风范。也是，如果两者都有好处，作为提供“机制”的内核来说为什么不都支持，让我们自己根据需要去选择呢？

如果从实现异步IO来讲，个人不赞成threadlets的方式，确实没有必要搞那么多线程，用任务队列就够了，既能发挥smp/multi-core系统的计算能力，又可以节约空间，至于编码的复杂度...，不要忘了做内核是什么最重要！况且异步IO本身不就是事件驱动的编程模型吗？有什么理由非要用线程来实现？

一家之言，结果如何，只能拭目以待！

参考资料:

[1]
[2]
[3] 
[4]