应用程序：一个异步的HTTP服务器的设计 假设我们要设计一个HTTP服务器，它的设计目标包括：高并发性、精简（部分支持HTTP/1.1）、支持plug-in结构。在不少场合可能都有这个需求。总体上来说，HTTP服务器可以类比成一个基于多线程的操作系统：OS调度每个工作线程在适当的时候获得执行，而工作线程提供服务（也就是处理HTTP请求）。在这个基础上，主要的考虑就是调度粒度的大小，粒度太大的时候并发性会降低，而粒度太小又可能因为任务切换（考虑OS的Context Switching）而导致效率降低，所以这又是一个折衷的结果。类似于Apache（以及其他的HTTP服务器），我们可以把一个HTTP处理过程分为若干个状态，基于这些状态可以构造出一个HTTP处理的状态机。这种情况下，我们就可以把每个状态的处理作为调度的粒度。一个调度过程就是：一个工作线程从全局的任务队列里取出一个HTTP_Context结构；根据当前的状态完成相应处理；然后根据状态机设置下一个状态；再放回到全局的任务队列里。这样子，若干个HTTP状态就可以通过这个调度策略构成一个完整HTTP处理过程。显而易见，一个状态对于下一个状态处理的调用都可以认为是异步的。一个HTTP状态机的设计如下图所示。
工作线程的函数其实就是两个操作：从状态队列里取出一个HTTP_Context，调用HTTP_Context的service()函数，周而复此。在这个架构上，就很容易引入异步I/O和Plug-in的机制了。事实上我们也可以使用基于事件（例如select/poll）的I/O策略来模拟异步I/O，实现中使用一个tb用户线程就可以了。
对于异步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），当例外的情况不多的时候是可以接受的。这时候可以说事件的报告就只是近似的。