 图1. HTTP状态机 |
工作线程的函数其实就是两个操作：从状态队列里取出一个HTTP_Context，调用HTTP_Context的service()函数，周而复此。在这个架构上，就很容易引入异步I/O和Plug-in的机制了。事实上我们也能够使用基于事件（例如select/poll）的I/O策略来模拟异步 I/O，实现中使用一个用户线程就能够了。
对于异步I/O和Plug-in的调用，我们也是采用类似于Linux 2.6里面aio的重试方案，而异步完成的时候采用回调函数。在某个状态上，假如系统需要I/O操作（recv或send），则会请求一个异步I/O （操作系统提供的异步I/O或由用户线程模拟的异步I/O），这时候相应的HTTP_Context不会重新回到状态队列里，而在I/O完成的回调函数里面才会重新放回到状态队列，得到重新调度的机会。HTTP_Context得到重新调度的时候会检查I/O状态（这个能够通过一些标志位来完成），假如已完成，则处理然后配置下一状态，重新调度，否则能够重新请求一个新的I/O请求。Plug-in也能够使用类似的方案，比如说一个Plug-in要跟外部的一个服务器通信，这时候就能够在通信完成的时候才把HTTP_Context重新放回到状态队列。显然，Plug-in跟HTTP状态是多对多的关系，一个Plug-in能够在若干个关心的状态注册自身，同时还能够配置一些short-path来提高处理的效率。
结论
总的来说，异步调用的设计和应用归根结底就是对多个主动对象的管理问题：如何提供执行的动力连同如何确保执行的顺序逻辑。主要考虑的问题是主动对象的粒度连同执行方式，同步或回调来完成顺序的调度，或使用近似的调度而加一些鲁棒的错误处理机制来确保语义的正确。后者能够考虑在使用基于事件的 socket的时候，readable事件的通知能够是冗余的，或说能够比实际中发生的readable事件更多，这个时候使用非阻塞的socket, 有些read()（或recv()）会直接返回EWOULDBLOCK，系统只要考虑处理这种情况（使用non blocking socket而不是blocking socket），当例外的情况不多的时候是能够接受的。这时候能够说事件的报告就只是近似的。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
