[原创]再论epoll

学习时间的过程终会有反复，其中也包括一些错误，上午对于前一篇关于epoll的文章进行了增改，下午就觉得有些不妥，重新编辑感觉不太容易剥楼错误，现在有些新的变化在这里重新论述。

上午说的在epoll里面进行耗时任务的时候做一个任务调度器（比如当服务器连接外部资源），这说明我只了解了epoll的一部份，没有充分认识到它的普 遍意义的应用，其实对于外部连接epoll可以作为服务器端的任务调度器使用，但是它同样适用于主动式连接的socket，换言之，如果服务器需要连接外 部socket资源也同样可以将它连接的道德socket fd加入epoll的监视，这样epoll的调度就更有广泛了，所有需要socklet交互的部分都可以交由epoll，然后他负责监制EPOLLIN和 EPOLLOUT两个事件，这两个事件的组合多次利用就可以构成整个服务事件驱动机制，所以我上午说的任务调度其也是多余的。

有人可能想了，那么对于多核服务器不久没有任何优势了么？我的设想是这样的，先在单线程的模型上完成开发，如果想扩展到多核，可以在epoll的下面再次 构建一个多线程的任务调度器，也就是将epoll检测到的事件再次保存到一个结构体，用多线程去读取并处理事件，这样不会影响大部分的代码，真正的程序不 是直接响应epoll事件，而是在新的任务调度器下面统一处理epoll事件的副本，这样就有epoll主动事件驱动调用变成了异步的，多线程并行执行的 模型，但是每个连接同一时间也只有一个线程在处理，现在还没有经过实际测试，不确信对于性能的影响如何。

如果所有实际的处理过程暂用cpu很短那么加上我上面设计的一层任务调度就是多余的，因为所以的问题都会集中体现在网络上，这不是服务器所能解决的，如果 网络快到了事件在等待任务，那么这种模型才有可能有较好的表现，所以是否应用还是要看具体的服务内容，事实证明单线程已经处理的足够快了，每秒1万页的处 理速度能满足绝大多数的需求，所以就设计而言，关键问题还是要解决瓶颈，而不是将所有想到的好技术都应用上，瓶颈可能还没有得到解决，反而更加浪费cpu 资源。

所以我觉决定还是全部以epoll驱动去做这个web架构，毕竟nginx等都有上佳的表现，这样看来做个代理或者反项代理也是很容易的，还可以更加节约资源

看了这么久才算对于nginx等处理模型有了个大致的了解，起初打算更改它的代码，后来发现太麻烦了，所以重新自己架构，走下来发现只要了解思路了具体的技术是很快的，不然看别人的代码太辛苦了