- 论坛徽章:
- 0
|
本帖最后由 huxk 于 2010-12-12 17:17 编辑
摘录原文两段话
1 Obviously this provides us with the advantage of always picking up a filehandle that will not block thus avoiding the possibility of delaying the entire program for one lazy filehandle just because it happened to be the first we picked at random. Still, it does not guarantee that the selected filehandle is the best choice, because we still don't know how much data can be read, or how qucikly it can take in data that we wrte to it. But it is definetly a big step forward from our initial program.
2 As we already mentioned earlier, this method does not guarantee progress as it only tests whether a handle is ready to respond to I/O. The question still remains, whether the handle we pick from the ready ones is the one that will respond faster to I/O, and how much data there is available for reading or how much data it is ready to receive. So it is still possible to block a bit after the point where we picked the handle. Also, we did not take into account the impact on performance that the actual processing of requests will have. We might just be printing incoming data to a file, but then again, each request might need heavy processing that would slow down the entire handle processing loop. But these are issues that must be considered in the context of the individual application.
这两段话已经解释得很明白 这就是为什么 select poll epoll被称为 伪异步 的原因吧 充分将CPU时间利用起来 当一组handle都是活跃分子的的时候 select 比 epoll效率高 但有handle数目限制 apache对此有解决办法 通过多进程
不知道perl是否支持windows的完成端口 那个可以直接取得IO结果 |
|