久久精品在这里,欧美在线影院,欧美高清在线

walkspeed — Tue, 27 Feb 2007 13:47:00 GMT

摘要: 9.1 意图　接受器－�q�接器设计模式（Acceptor-Connector�Q��分布式系�l�中的连接徏立及服务初始化与一旦服务初始化后所执行的处理去耦合。这��L��去耦合通过三种�l��g来完成：acceptor、connector和service handler�Q�服务处理器�Q�。连接器��d��地徏立到�q�地接受器组件的�q�接�Q��ƈ初始化服务处理器来处理在�q�接上交... 阅读全文

walkspeed 2007-02-27 21:47 发表评论

ACE的接受器�Q�Acceptor�Q�和�q�接器（Connector�Q�：�q�接建立模式

walkspeed — Tue, 27 Feb 2007 13:40:00 GMT

摘要: 接受�?�q�接器模式设计用于降低连接徏立与�q�接建立后所执行的服务之间的耦合。例如，在WWW��览器中�Q�所执行的服务或“实际工作”是解析和显�C�客��h��览器接收到的HTML��面。连接徏立是�ơ要的，可能通过BSD socket或其他一些等��L��IPC机制来完成。��用这些模式允许程序员专注于“实际工作”，而最��限度地��d��心怎样在服务器和客户之间徏立连接。而另外一斚w��Q�程序员也可以独立于他所�~�写的、或��要�~�写的服�?.. 阅读全文

walkspeed 2007-02-27 21:40 发表评论

转蝲一片关于前摄器�Q�Proactor�Q�的文章

walkspeed — Tue, 27 Feb 2007 13:17:00 GMT

�W?/b> 8 �?/b> 前摄器（ Proactor �Q�：用于为异步事件多路分��d��分派处理器的对象行�ؓ模式

　

Irfan Pyarali Tim Harrison Douglas C. Schmidt Thomas D. Jordan

　

�?/b> �?/b>

　

��C��操作�pȝ��为开发�ƈ发应用提供了多种机制。同步多�U�程是一�U�流行的机制�Q�用于开发同时执行多个操作的应用。但是，�U�程常常有很高的性能开销�Q��ƈ且需要对同步模式和原理有深入的了解。因此，有越来越多的操作�pȝ��支持异步机制�Q�在减少多线�E�的大量开销和复杂性的同时�Q�提供了�q�发的好处�?/i>

本论文中介绍的前摄器�Q�Proactor �Q�模式描�q�怎样构造应用和�pȝ��Q�以有效地利用操作系�l�支持的异步机制。当应用调用异步操作�Ӟ��OS 代表应用执行此操作。这使得应用可以让多个操作同时运行，而又不需要应用拥有相应数目的�U�程。因此，通过使用更少的线�E�和有效利用OS 对异步操作的支持�Q�前摄器模式��化了�q�发�~�程�Q��ƈ改善了性能�?/i>

　

8.1 意图

　

前摄器模式支持多个事件处理器的多路分��d��分派�Q�这些处理器由异步事件的完成来触发。通过集成完成事�g�Q�completion event�Q�的多�\分离和相应的事�g处理器的分派�Q�该模式��化了异步应用的开发�?/div>
　

8.2 动机

　

�q�一部分提供使用前摄器模式的上下文和动机�?/div>
　

8.2.1 上下文和压力

　

前摄器模式应该被用于应用需要�ƈ发执行操作的性能好处、又不想受到同步多线�E�或反应式编�E�的�U�束时。�ؓ说明�q�些好处�Q�设想一个需要�ƈ发执行多个操作的�|�络应用。例如，一个高性能Web服务器必��dƈ发处理发送自多个客户的HTTP��h��[1, 2]。图8-1 昄��了Web��览器和Web服务器之间的典型交互。当用户指示��览器打开一个URL�Ӟ��览器发送一个HTTP GET��h��l�Web服务器。收到请求，服务器就解析�q�校验请求，�q�将指定的文件发回给��览器�?/div>
　

500)this.style.width=500;" />

　

�?-1 典型的Web服务器通信软�g体系�l�构

　

开发高性能Web服务器要求消除以下压力：

　

�q�发�?/i>�Q�服务器必须同时执行多个客户��h��Q?

效率�Q�服务器必须最��化响应延迟、最大化吞吐量，�q��免不必要��C��用CPU�Q?

�~�程��单�?/i>�Q�服务器的设计应该简化高效的�q�发�{�略的��用；

可适配�?/i>�Q�应该�ɾl�承新的或改�q�的传输协议�Q�比如HTTP 1.1[3]�Q�所带来的维护代��h��化�?

　

Web服务器可以��用若�q��ƈ发策略来实现�Q�包括多个同步线�E�、反应式同步事�g分派和前摄式异步事�g分派。下面，我们��查传�l�方法的�~�点�Q��ƈ解释前摄器模式是怎样提供一�U�强大的技术，为高性能�q�发应用而支持高效、灵�zȝ��异步事�g分派�{�略的�?/div>
　

8.2.2 传统�q�发模型的常见陷阱和�~�陷

　

同步的多�U�程和反应式�~�程是实现�ƈ发的常用�Ҏ��。这一部分描述�q�些�~�程模型的缺炏V�?/div>
　

8.2.2.1 通过多个同步�U�程实现的�ƈ�?/b>

　
或许最为直观的实现�q�发Web服务器的途径是��?i>同步的多�U�程。在此模型中�Q�多个服务器�U�程同时处理来自多个客户的HTTP GET��h��。每个线�E�同步地执行�q�接建立、HTTP��h��d��、请求解析和文�g传输操作。作为结果，每个操作都阻塞直到完成�?/div>
同步�U�程的主要优�Ҏ��应用代码的简化。特别是�Q�Web服务器�ؓ服务客户A的请求所执行的操作在很大�E�度上独立于为服务客户B的请求所需的操作。因而，很容易在分离的线�E�中对不同的��h��q�行服务�Q�因为在�U�程之间�׃�n的状态数量很��；�q�也最��化了对同步的需要。而且�Q�在分离的线�E�中执行应用逻辑也��得开发者可以��用直观的��序命��o和阻塞操作�?/div>
　

500)this.style.width=500;" />

　

�?-2 多线�E�Web服务器体�pȝ��?/div>
　

�?-2昄��使用同步�U�程来设计的Web服务器怎样�q�发地处理多个客戯��求。该图显�C�的Sync Acceptor对象��装服务器端用于同步接受�|�络�q�接的机制。��用“Thread Per Connection”�ƈ发模型，各个�U�程为服务HTTP GET��h��所执行的一�p�d��步骤可被�ȝ��如下�Q?/div>
　

每个�U�程同步地阻塞在accept socket调用中，�{�待客户�q�接��h��Q?

客户�q�接到服务器�Q�连接被接受�Q?

新客��L��HTTP��h��被同步地从网�l�连接中��d��Q?

��h��被解析；

所��h��的文件被同步地读取；

文�g被同步地发送给客户�?

　

附录A.1中有一个将同步�U�程模型应用于Web服务器的C++代码例子�?/div>
如上所�q�ͼ�每个�q�发地连接的客户�׃��个专用的服务器线�E�服务。在�l�箋为其他HTTP��h��服务之前�Q�该�U�程同步地完成一个被��h��的操作。因此，要在服务多个客户时执行同步I/O�Q�Web服务器必��L��生多个线�E�。尽��这�U�同步线�E�模式是直观的，且能够相寚w��效地映射到多CPU�q�_��上，它还是有以下�~�点�Q?/div>
　

�U�程�{�略与�ƈ发策略被紧耦合�Q?/b>�q�种体系�l�构要求每个相连客户都有一个专用的�U�程。通过针对可用资源�Q�比如��用线�E�池来对应CPU的数目）、而不是正被�ƈ发服务的客户的数目来调整其线�E�策略，可能会更好地优化一个�ƈ发应用；

　

更大的同步复杂性：�U�程可能会增加序列化�Ҏ��务器的共享资源（比如�~�存文�g和Web��面点击日志�Q�的讉K��所必需的同步机制的复杂性；

　

更多的性能开销�Q?/b>�׃��上下文切换、同步和CPU间的数据�U�d��[4]�Q�线�E�的执行可能很低效；

　

不可�U�L��性：�U�程有可能在有些�q�_��上不可用。而且�Q�根据对占先式和非占先式�U�程的支持，OS�q�_��之间的差异非常大。因而，很难构徏能够跨��^台统一�q�作的多�U�程服务器�?/div>
　

作�ؓ�q�些�~�点的结果，多线�E�常�怸�是开发�ƈ发Web服务器的最为高效的、也不是最不复杂的解决�Ҏ��?/div>
　

8.2.2.2 通过反应式同步事件分�z�֮�现的�q�发

　

另一�U�实现同步Web服务器的常用�Ҏ��是��?i>反应式事件分�z?/i>模型。反应堆�Q�Reactor�Q�模式描�q�应用怎样��Event Handler登记到Initiation Dispatcher。Initiation Dispatcher通知Event Handler何时能发起一��Ҏ��作而不��d��?/div>
单线�E��ƈ发Web服务器可以��用反应式事�g分派模型�Q�它在一个事件��@环中�{�待Reactor通知它发起适当的操作。Web服务器中反应式操作的一个例子是Acceptor�Q�接受器�Q�[6]到Initiation Dispatcher的登记。当数据在网�l�连接上到达�Ӟ��分派器回调Acceptor�Q�后者接受网�l�连接，�q�创建HTTP Handler。于是这个HTTP Handler��q��记到Reactor�Q�以在Web服务器的单线�E�控制中处理在那个连接上到来的URL��h��?/div>
�?-3和图8-4昄��使用反应式事件分�z�设计的Web服务器怎样处理多个客户。图8-3昄��当客戯��接到Web服务器时所采取的步骤。图8-4昄��Web服务器怎样处理客户��h��。图8-3的一�p�d��步骤可被�ȝ��如下�Q?/div>
　

500)this.style.width=500;" />

　

�?-3 客户�q�接到反应式Web服务�?/div>
　

500)this.style.width=500;" />

　

�?-4 客户发送HTTP��h��到反应式Web服务�?/div>
　

Web服务器将Acceptor登记到Initiation Dispatcher�Q�以接受新连接；

Web服务器调用Initiation Dispatcher的事件��@环；

客户�q�接到Web服务器；

Initiation Dispatcher��新�q�接��h��通知Acceptor�Q�后者接受新�q�接�Q?

Acceptor创徏HTTP Handler�Q�以服务新客��P��

HTTP Handler��连接登记到Initiation Dispatcher�Q�以��d��客户��h��数据�Q�就是说�Q�在�q�接变得“读��q�A”时�Q�；

HTTP Handler服务来自新客��L��h��?

　

�?-4昄��反应式Web服务器�ؓ服务HTTP GET��h��所采取的一�p�d��步骤。该�q�程描述如下�Q?/div>
　

客户发送HTTP GET��h��Q?

当客戯��求数据到达服务器�Ӟ��Initiation Dispatcher通知HTTP Handler�Q?

��h��以非��d��方式被读取，于是如果操作会导致调用线�E�阻塞，��L��作就�q�回EWOULDBLOCK�Q�步�?�?��重复直到请求被完全��d��Q�；

HTTP Handler解析HTTP��h��Q?

所��h��的文件从文�g�pȝ��中被同步��d��Q?

为发送文件数据（��是��_��当连接变得“写��q�A”时�Q�，HTTP Handler��连接登记到Initiation Dispatcher�Q?

当TCP�q�接变得写就�l�时�Q�Initiation Dispatcher通知HTTP Handler�Q?

HTTP Handler以非��d��方式��所��h��文�g发送给客户�Q�于是如果操作会��D��调用�U�程��d��Q�写操作��p��回EWOULDBLOCK�Q�步�?�?��重复直到数据被完全递送）�?

　

附录A.2中有一个将反应式事件分�z�模型应用于Web服务器的C++代码例子�?/div>
因�ؓInitiation Dispatcher�q�行在单�U�程中，�|�络I/O操作以非��d��方式�q�行在Reactor的控制之下。如果当前操作的�q�度停止了，操作��p��转手�l�Initiation Dispatcher�Q�由它监控系�l�操作的状态。当操作可以再度前进�Ӟ��适当的Event Handler会被通知�?/div>
反应式模式的主要优点是可�U�L��性，�_�粒度�ƈ发控制带来的低开销�Q�就是说�Q�单�U�程不需要同步或上下文切换）�Q�以及通过使应用逻辑与分�z�机制去耦合所获得的模块性。但是，该方法有以下�~�点�Q?/div>
　

复杂的编�E�：如从前面的列表所看到的，�E�序员必��ȝ��写复杂的逻辑�Q�以保证服务器不会在服务一个特定客��h��d��?/div>
　

�~�Z��多线�E�的OS 支持�Q?/b>大多数操作系�l�通过select�pȝ��调用[7]来实现反应式分派模型。但是，select不允许多于一个的�U�程在同一个描�q�符集上�{�待。这使得反应式模型不适用于高性能应用�Q�因为它没有有效地利用硬件的�q�行性�?/div>
　

可运行�Q务的调度�Q?/b>在支持占先式�U�程的同步多�U�程体系�l�构中，��可�q�行�U�程调度�q�时分（time-slice�Q�到可用CPU上是操作�pȝ��的责仅R��这��L��调度支持在反应式体系�l�构中不可用�Q�因为在应用中只有一个线�E�。因此，�pȝ��的开发者必��d��心地在所有连接到Web服务器的客户之间��线�E�分时。这只能通过执行短持�l�时间、非��d��的操作来完成�?/div>
　

作�ؓ�q�些�~�点的结果，当硬件�ƈ行可用时�Q�反应式事�g分派不是最为高效的模型。由于需要避免��用阻塞I/O�Q�该模式�q�有着相对较高的编�E�复杂度�?/div>
　

8.2.3 解决�Ҏ��Q�通过前摄式操作实现的�q�发

　

当OS�q�_��支持异步操作�Ӟ��一�U�高效而方便的实现高性能Web服务器的�Ҏ��是��?i>前摄式事件分�z?/i>。��用前摄式事�g分派模型设计的Web服务器通过一或多个线�E�控制来处理异步操作的完成。这��P��通过集成完成事�g多�\分离�Q?/i>completion event demultiplexing�Q�和事�g处理器分�z�，前摄器模式简化了异步的Web服务�?/i>�?/div>
异步的Web服务器将�q�样来利用前摄器模式�Q�首先让Web服务器向OS发出异步操作�Q��ƈ��回调方法登记到Completion Dispatcher�Q�完成分�z�֙��Q�，后者将在操作完成时通知Web服务器。于是OS代表Web服务器执行操作，�q��卛_��一个周知的地方��结果排队。Completion Dispatcher负责使完成通知出队�Q��ƈ执行适当的、含有应用特有的Web服务器代码的回调�?/div>
　

500)this.style.width=500;" />

　

�?-5 客户�q�接到基于前摄器的Web服务�?/div>
　

500)this.style.width=500;" />

　

�?-6 客户发送请求给��Z��前摄器的Web服务�?/div>
　

�?-5和图8-6昄��使用前摄式事件分�z�设计的Web服务器怎样在一或多个线�E�中�q�发地处理多个客戗��图8-5昄��当客戯��接到Web服务器时所采取的一�p�d��步骤�?/div>
　

Web服务器指�C�Acceptor发�v异步接受�Q?

接受器通过OS发�v异步接受�Q�将其自�w�作为Completion Handler和Completion Dispatcher的引用传递；�q�将用于在异步接受完成时通知Acceptor�Q?

Web服务器调用Completion Dispatcher的事件��@环；

客户�q�接到Web服务器；

当异步接受操作完成时�Q�操作系�l�通知Completion Dispatcher�Q?

Completion Dispatcher通知接受器；

Acceptor创徏HTTP Handler�Q?

HTTP Handler发�v异步操作�Q�以��d��来自客户的请求数据，�q�将其自�w�作为Completion Handler和Completion Dispatcher的引用传递；�q�将用于在异步读取完成时通知HTTP Handler�?

　

�?-6 昄��前摄式Web服务器�ؓ服务HTTP GET��h��所采取的步骤。这些步骤解释如下：

　

客户发送HTTP GET��h��Q?

��d��操作完成�Q�操作系�l�通知Completion Dispatcher�Q?

Completion Dispatcher通知HTTP Handler�Q�步�?�?��重复直到整个请求被接收�Q�；

HTTP Handler解析��h��Q?

HTTP Handler同步地读取所��h��的文�Ӟ��

HTTP Handler发�v异步操作�Q�以把文件数据写到客戯��接，�q�将其自�w�作为Completion Handler和Completion Dispatcher的引用传递；�q�将用于在异步写入完成时通知HTTP Handler�?

当写操作完成�Ӟ��操作�pȝ��通知Completion Dispatcher�Q?

随后Completion Dispatcher通知Completion Handler�Q�步�?-8��重复直到文件被完全递送）�?

　

8.8中有一个将前摄式事件分�z�模型应用于Web服务器的C++代码例子�?/div>
使用前摄器模式的主要优点是可以启动多个�ƈ发操作，�q�可�q�行�q�行�Q�而不要求应用必须拥有多个�U�程。操作被应用异步地启动，它们在OS的I/O子系�l�中�q�行直到完成。发��h��作的�U�程现在可以服务另外的请求了�?/div>
例如�Q�在上面的例子中�Q�Completion Dispatcher可以是单�U�程的。当HTTP��h��到达�Ӟ��单个Completion Dispatcher�U�程解析��h��Q�读取文�Ӟ��q�发送响应给客户。因为响应是被异步发送的�Q�多个响应就有可能同时被发送。而且�Q�同步的文�g��d��可以被异步的文�g��d��取代�Q�以�q�一步增加�ƈ发的潜力。如果文件读取是被异步完成的�Q�HTTP Handler所执行的唯一的同步操作就只剩下了HTTP协议��h��解析�?/div>
前摄式模型的主要�~�点是编�E�逻辑臛_��和反应式模型一样复杂。而且�Q�前摄器模式可能会难以调试，因�ؓ异步操作常常有着不可预测和不可重复的执行序列�Q�这��׃��分析和调试复杂化了�?.7描述怎样应用其他模式�Q�比如异步完成��o牌[8]�Q�来��化异步应用编�E�模型�?/div>
　

8.3 适用�?/b>

　

当具有以下一��Ҏ��多项条�g时��用前摄器模式�Q?/div>
　

应用需要执行一个或多个不阻塞调用线�E�的异步操作�Q?

当异步操作完成时应用必须被通知�Q?

应用需要独立于它的I/O模型改变它的�q�发�{�略�Q?

通过使依赖于应用的逻辑与应用无关的底层构造去耦合�Q�应用将从中��L��Q?

当��用多�U�程�Ҏ��或反应式分派�Ҏ��Ӟ��应用的执行将很低效，或是不能满��性能需求�?

　

8.4 �l�构和参与�?/b>

　

在图8-7中��用OMT表示法演�C�Z��前摄器模式的�l�构�?/div>
前摄器模式中的关键参与者包括：

　

前摄发�v�?/b>�Q�Proactive Initiator。Web服务器应用的�ȝ��E�）�Q?/div>
　

Proactive Initiator是应用中��M��发�vAsynchronous Operation�Q�异步操作）的实体。它��Completion Handler和Completion Dispatcher登记到Asynchronous Operation Processor�Q�异步操作处理器�Q�，此处理器在操作完成时通知前摄发�v器�?

　

完成处理�?/b>�Q�Completion Handler。Acceptor和HTTP Handler�Q�：

　

前摄器模式将应用所实现的Completion Handler接口用于Asynchronous Operation完成通知�?

　

异步操作�Q�Asynchronous Operation。Async_Read、Async_Write和Async_Accept�Ҏ��Q�：

　

Asynchronous Operation被用于代表应用执行请求（比如I/O和定时器操作�Q�。当应用调用Asynchronous Operation�Ӟ��操作的执�?i>没有借用应用的线�E�控制。因此，从应用的角度来看�Q�操作是�?i>异步�?/i>执行的。当Asynchronous Operation完成�Ӟ��Asynchronous Operation Processor��应用通知委托�l�Completion Dispatcher�?

　

异步操作处理�?/b>�Q�Asynchronous Operation Processor。操作系�l�）�Q?/div>
　

Asynchronous Operation是由Asynchronous Operation Processor来运行直臛_��成的。该�l��g通常由OS实现�?

　

完成分派�?/b>�Q�Completion Dispatcher。Notification Queue�Q�：

　

Completion Dispatcher负责在Asynchronous Operation完成时回调应用的Completion Handler。当Asynchronous Operation Processor完成异步发�v的操作时�Q�Completion Dispatcher代表应用执行应用回调�?

　

500)this.style.width=500;" />

　

�?-7 前摄器模式中的参与�?/div>
　

8.5 协作

　

有若�q�良好定义的步骤被用于所有Asynchronous Operation。在高水�q�的抽象上，应用异步地发��h��作，�q�在操作完成时被通知。图8-8昄��在模式参与者之间必定发生的下列交互�Q?/div>
　

前摄发�v器发��h��作：为执行异步操作，应用在Asynchronous Operation Processor上发��h��作。例如，Web服务器可能要求OS在网�l�上使用特定的socket�q�接传输文�g。要��h��q�样的操作，Web服务器必��L��定要使用哪一个文件和�|�络�q�接。而且�Q�Web服务器必��L��定（1�Q�当操作完成旉��知哪一个Completion Handler�Q�以及（2�Q�一旦文件被传输�Q�哪一个Completion Dispatcher应该执行回调�?

异步操作处理器执行操作：当应用在Asynchronous Operation Processor上调用操作时�Q�它相对于其他应用操作异步地�q�行�q�些操作。现代操作系�l�（比如Solaris和Windows NT�Q�在内核中提供异步的I/O子系�l��?

异步操作处理器通知完成分派器：当操作完成时�Q�Asynchronous Operation Processor取得在操作被发�v时指定的Completion Handler和Completion Dispatcher。随后Asynchronous Operation Processor��Asynchronous Operation的结果和Completion Handler传递给Completion Dispatcher�Q�以用于回调。例如，如果文�g已被异步传输�Q�Asynchronous Operation Processor可以报告完成状态（比如成功或失败）�Q�以及写入网�l�连接的字节数�?

完成分派器通知应用�Q?/b>Completion Dispatcher在Completion Handler上调用完成挂钩，��由应用指定的�Q何完成数据传递给它。例如，如果异步��d��完成�Q�通常一个指向新到达数据的指针将会被传递给Completion Handler�?

　

500)this.style.width=500;" />

　

�?-8 前摄器模式的交互�?/div>
　

8.6 效果

　

�q�一部分详述使用前摄器模式的效果�?/div>
　

8.6.1 好处

　

前摄器模式提供以下好处：

　

增强事务分离�Q?/b>前摄器模式��应用无关的异步机制与应用�Ҏ��的功能去耦合。应用无关的机制成�ؓ可复用组�Ӟ��知道怎样多�\分离与Asynchronous Operation相关联的完成事�g�Q��ƈ分派适当的由Completion Handler定义的回调方法。同样地�Q�应用特有的功能知道怎样执行特定�c�d��的服务（比如HTTP处理�Q��?/div>
　

改善应用逻辑可移植性：通过允许接口独立于执行事件多路分��ȝ��底层OS调用而复用，它改善了应用的可�U�L��性。这些系�l�调用检��ƈ报告可能同时发生在多个事件源之上的事件。事件源可以是I/O端口、定时器、同步对象、信��P��{�等。在实时POSIX�q�_��上，异步I/O函数由aio API族[9]提供。在Windows NT中，I/O完成端口和重叠式�Q�overlapped�Q�I/O被用于实现异步I/O[10]�?/div>
　

完成分派器封装了�q�发机制�Q?/b>使Completion Dispatcher与Asynchronous Operation Processor去耦合的一个好处是应用可以通过多种�q�发�{�略来配�|�Completion Dispatcher�Q�而不会媄响其他参与者。如8.7所讨论的，Completion Dispatcher可被配置使用包括单线�E�和�U�程池方案在内的若干�q�发�{�略�?/div>
　

�U�程�{�略被与�q�发�{�略去耦合�Q?/b>因�ؓAsynchronous Operation Processor代表Proactive Initiator完成可能长时间运行的操作�Q�应用不会被�q�派生线�E�来增加�q�发。这使得应用可以独立于它的线�E�策略改变它的�ƈ发策略。例如，Web服务器可能只��x��个CPU有一个线�E�，但又惛_��时服务更多数目的客户�?/div>
　

提高性能�Q?/b>多线�E�操作系�l�执行上下文切换�Q�以在多个线�E�控制中轮换。虽然执行一�ơ上下文切换的时间保持相当的恒定�Q�如果OS上下文要切换到空闲线�E�的话，在大量线�E�间轮换的��L��间可以显著地降低应用性能。例如，�U�程可以轮询OS以查看完成状态，而这是低效率的。通过只激�z�那些有事�g要处理的合理的线�E�控�Ӟ��前摄器模式能够避免上下文切换的代仗��例如，如果没有待处理的GET��h��Q�Web服务器不需要启用HTTP Handler�?/div>
　

应用同步的简化：只要Completion Handler不派生另外的�U�程控制�Q�可以不考虑、或只考虑��许同步问题而编写应用逻辑。Completion Handler可被�~�写为就好像它们存在于一个传�l�的单线�E�环境中一栗��例如，Web服务器的HTTP GET处理器可以通过Async Read操作�Q�比如Windows NT TransmitFile函数[1]�Q�来讉K��盘�?/div>
　

8.6.2 �~�点

　

前摄器模式有以下�~�点�Q?/div>
　

难以调试�Q?/b>以前摄器模式�~�写的应用可能难以调试，因�ؓ反向的控制流在构架基��l�构和应用特有的处理器上的回调方法之间来回振荡。这增加了在调试器中�Ҏ��架的�q�行时行为的“单步跟�t�”的困难度，因�ؓ应用开发者可能不了解或不能获得构架的代码。这与试图调试��用LEX和YACC�~�写的编译器的词法分析器和解析器时所遇到的问题是�c�M��的。在�q�些应用中，当线�E�控制是在用户定义的动作例程中时�Q�调试是相当直接的。但是一旦线�E�控制返回到所生成的有限确定自动机�Q�Deterministic Finite Automate�Q�DFA�Q�骨架时�Q�就很难跟住�E�序逻辑了�?/div>
　

调度和控制未完成操作�Q?/b>Proactive Initiator可能没有对Asynchronous Operation的执行顺序的控制。因此，Asynchronous Operation Processor必须被小心设计，以支持Asynchronous Operation的优先��和取消处理�?/div>
　

8.7 实现

　

前摄器模式可以通过许多方式实现。这一部分讨论实现前摄器模式所涉及的步骤�?/div>
　

8.7.1 实现异步操作处理�?/b>

　

实现前摄器模式的�W�一步是构徏Asynchronous Operation Processor。该�l��g负责代表应用异步地执行操作。因此，它的两项主要责�Q是输出Asynchronous Operation API和实现Asynchronous Operation Engine以完成工作�?/div>
　

8.7.1.1 定义异步操作 API

　

Asynchronous Operation Processor必须提供API、允许应用请求Asynchronous Operation。在设计�q�些API时有若干压力需要考虑�Q?/div>
　

可移植性：此API不应�U�束应用或它的Proactive Initiator使用特定的��^台�?/div>
　

灉|��性：常常�Q�异步API可以��多类型的操作�׃�n。例如，异步I/O操作常常被用于在多种介质�Q�比如网�l�和文�g�Q�上执行I/O。设计支持这��L��复用的API可能是有益的�?/div>
　

回调�Q?/b>当操作被调用�Ӟ��Proactive Initiator必须登记回调。实现回调的一�U�常用方法是让调用对象（客户�Q�输出接口、让调用者知道（服务器）。因此，Proactive Initiator必须通知Asynchronous Operation Processor�Q�当操作完成�Ӟ��哪一个Completion Handler应被回调�?/div>
　

完成分派器：因�ؓ应用可以使用多个Completion Dispatcher�Q�Proactive Initiator�q�必��L��C�由哪一个Completion Dispatcher来执行回调�?/div>
　

�l�定所有这些问题，考虑下面的用于异步读写的API。Asynch_Stream�c�L��用于发�v异步��d��的工厂。一旦构造，可以使用此类来启动多个异步读写。当异步��d��完成�Ӟ��Asynch_Stream::Read_Result��通过Completion_Handler上的handler_read回调�Ҏ��被回传给handler。类似地�Q�当异步写入完成�Ӟ��Asynch_Stream::Write_Result��通过Completion_Handler上的handler_write回调�Ҏ��被回传给handler�?/div>
　

class Asynch_Stream

// = TITLE

// A Factory for initiating reads

// and writes asynchronously.

{

// Initializes the factory with information

// which will be used with each asynchronous

// call. is notified when the

// operation completes. The asynchronous

// operations are performed on the

// and the results of the operations are

// sent to the .

Asynch_Stream (Completion_Handler &handler,

HANDLE handle,

Completion_Dispatcher *);

　

// This starts off an asynchronous read.

// Upto will be read and

// stored in the .

int read (Message_Block &message_block,

u_long bytes_to_read,

const void *act = 0);

　

// This starts off an asynchronous write.

// Upto will be written

// from the .

int write (Message_Block &message_block,

u_long bytes_to_write,

const void *act = 0);

　

...

};

　

8.7.1.2 实现异步操作引擎

　

Asynchronous Operation Processor必须含有异步执行操作的机制。换句话��_��当应用线�E�调用Asynchronous Operation�Ӟ��必须不借用应用的线�E�控制而执行此操作。幸好，��C��操作�pȝ��提供了用于Asynchronous Operation的机�Ӟ��例如�Q�POSIX 异步I/O和WinNT重叠式I/O�Q�。在�q�样的情况下�Q�实现模式的�q�一部分只需要简单地��^台API映射��C��面描�q�的Asynchronous Operation API�?/div>
如果OS�q�_��不提供对Asynchronous Operation的支持，有若�q�实现技术可用于构徏Asynchronous Operation Engine。或许最为直观的解决�Ҏ��是��用专用线�E�来为应用执行Asynchronous Operation。要实现�U�程化的Asynchronous Operation Engine�Q�有三个主要步骤�Q?/div>
　

操作调用�Q?/b>因�ؓ操作��在与进行调用的应用�U�程不同的线�E�控制中执行�Q�必定会发生某种�c�d��的线�E�同步。一�U�方法是为每个操作派生一个线�E�。更为常用的�Ҏ��是�ؓAsynchronous Operation Processor而管理一个专用线�E�池。该�Ҏ��可能需要应用线�E�在�l�箋�q�行其他应用计算之前��操作请求排队�?

操作执行�Q?/b>既然操作��在专用�U�程中执行，所以它可以执行“阻塞”操作，而不会直接阻��应用的�q�展。例如，在提供异步I/O��d��机制�Ӟ��专用�U�程可以在从socket或文件句柄中��L��d��?

操作完成�Q?/b>当操作完成时�Q�应用必��被通知到。特别是�Q�专用线�E�必��d��应用�Ҏ��的通知委托�l�Completion Dispatcher。这要求在线�E�间�q�行另外的同步�?

　

8.7.2 实现完成分派�?/b>

　

当Completion Dispatcher从Asynchronous Operation Processor接收到操作完成通知�Ӟ��它会回调与应用对象相兌��的Completion Handler。实现Completion Dispatcher涉及两个问题�Q�（1�Q�实现回调以及（2�Q�定义用于执行回调的�q�发�{�略�?/div>
　

8.7.2.1 实现回调

　

Completion Dispatcher必须实现一�U�机�Ӟ��Completion Handler通过它被调用。这要求Proactive Initiator在发��h��作时指定一个回调。下面是常用的回调可选方案：

　

回调�c�：Completion Handler输出接口、让Completion Dispatcher知道。当操作完成�Ӟ��Completion Dispatcher回调此接口中的方法，�q�将已完成操作的有关信息传递给它（比如从网�l�连接中��d��的字节数�Q��?/div>
　

函数指针�Q?/b>Completion Dispatcher通过回调函数指针来调用Completion Handler。该�Ҏ��有效地打破了Completion Dispatcher和Completion Handler之间的知识依赖。这有两个好处：

　

Completion Handler不会被迫输出特定的接口；以及

在Completion Dispatcher和Completion Handler之间不需要有�~�译时依赖�?

　

会合点：Proactive Initiator可以讄��事�g对象或条件变量，用作Completion Dispatcher和Completion Handler之间的会合点。这在Completion Handler是Proactive Initiator时最为常见。在Asynchronous Operation�q�行臛_��成的同时�Q�Completion Handler处理其他的活动。Completion Handler��在会合点周期性地��查完成状态�?/div>
　

8.7.2.2 定义完成分派器�ƈ发策�?/b>

　

当操作完成时�Q�Asynchronous Operation Processor��会通知Completion Dispatcher。在�q�时�Q�Completion Dispatcher可以利用下面的�ƈ发策略中的一�U�来执行应用回调�Q?/div>
　

动态线�E�分�z�：Completion Dispatcher可�ؓ每个Completion Handler动态分配一个线�E�。动态线�E�分�z�֏�通过大多数多�U�程操作�pȝ��来实现。在有些�q�_��上，�׃��创徏和销毁线�E�资源的开销�Q�这可能是所列出的Completion Dispatcher实现技术中最��Z��效的一�U�，

　

后反应式分派�Q�Post-reactive dispatching �Q�：Completion Dispatcher可以发信��L��Proactive Initiation所讄��的事件对象或条�g变量。尽��轮询和�z��d��在事件对象上的子�U�程都是可选的�Ҏ��Q�最为高效的后反应式分派�Ҏ��是将事�g登记到Reactor。后反应式分�z�֏�以通过POSIX实时环境中的aio_suspend和Win32环境中的WaitForMultipleObjects来实现�?/div>
　

Call-through 分派�Q?/b>来自Asynchronous Operation Processor的线�E�控制可被Completion Dispatcher借用�Q�以执行Completion Handler。这�U�“周期偷取”策略可以通过减少�I�闲�U�程的媄响范围来提高性能。在一些老操作系�l�会��上下文切换到空闲线�E�、又只是从它们切换出�ȝ��情况下，�q�种�Ҏ��有着收回“失�ȝ��”时间的巨大潜力�?/div>
Call-through分派在Windows NT中可以��用ReadFileEx和WriteFileEx Win32函数来实现。例如，�U�程控制可以使用�q�些调用来等待信号量被置位。当它等待时�Q�线�E�通知OS它进入了一�U�称为“可报警�{�待状态”（alterable wait state�Q�的�Ҏ��状态。在�q�时�Q�OS可以占有对等待中的线�E�控制的栈和相关资源的控�Ӟ��以执行Completion Handler�?/div>
　

�U�程池分�z�：由Completion Dispatcher拥有的线�E�池可被用于Completion Handler的执行。在池中的每个线�E�控制已被动态地分配到可用的CPU。线�E�池分派可通过Windows NT的I/O完成端口来实现�?/div>
　

在考虑上面描述的Completion Dispatcher技术的适用性时�Q�考虑�?-1中所�C�的OS环境和物理硬件的可能�l�合 �Q?br />
�U�程模型
�pȝ��c�d��
单处理器
多处理器
单线�E?/div>
A
B
多线�E?/div>
C
D
�?-1 Completion Dispatcher�q�发�{�略
　
如果你的OS只支持同步I/O�Q�那��参见反应堆模式[5]。但是，大多数现代操作系�l�都支持某种�c�d��的异步I/O�?/div>
在表8-1的A和B�l�合中，假定你不�{�待��M��信号量或互斥体，后反应方式的异步I/O很可能是最好的。否则，Call-through实现或许更能回应你的问题。在C�l�合中，使用Call-through�Ҏ��。在D�l�合中，使用�U�程池方法。在实践中，�pȝ��化的�l�验��量对于选择最为合适的可选方案来说是必需的�?/div>
　
8.7.3 实现完成处理�?/b>
　
Completion Handler的实现带来以下考虑�?/div>
　
8.7.3.1 状态完整�?/b>
　
Completion Handler可能需要维护关于特定请求的状态信息。例如，OS可以通知Web服务器，只有一部分文�g已被写到�|�络通信端口。作为结果，Completion Handler可能需要重新发��求，直到文�g被完全写出，或连接变得无效。因此，它必��ȝ��道原先指定的文�g�Q�还剩多��字节要写，以及在前一个请求开始时文�g指针的位�|��?/div>
没有隐含的限制来��L��Proactive Initiator��多个Asynchronous Operation��h��分配�l�单个Completion Handler。因此，Completion Handler必须在完成通知链中一一“系上”请求特有的状态信息。�ؓ完成此工作，Completion Handler可以利用异步完成令牌�Q�Asynchronous Completion Token�Q�模式[8]�?/div>
　
8.7.3.2 资源��理
　
与在��M��多线�E�环境中一��P��使用前摄器模式的Completion Handler�q�是要由它自己来��保对共享资源的讉K��是线�E�安全的。但是，Completion Handler不能跨越多个完成通知持有�׃�n资源。否则，��有发生“用��哲学家问题”的危险[11]�?/div>
该问题在于一个合理的�U�程控制�怹��{�待一个信号量被置位时所产生的死锁。通过设想一个由一��哲学家出席的宴会可以演�C��一问题。用��者围�l�一个圆桌就座，在每个哲学家之间只有一支筷子。当哲学家觉得饥饿时�Q�他必须获取在他左边和在他右边的�{�子才能用餐。一旦哲学家获得一支筷子，不到吃饱他们��׃��会放下它。如果所有哲学家都拿起在他们双��的筷子，��׃��发生死锁�Q�因��Z��们将永远也不可能拿到左边的筷子�?/div>
　
8.7.3.3 占先式策略（Preemptive Policy�Q?/b>
　
Completion Dispatcher�c�d��军_��在执行时一个Completion Handler是否可占先。当与动态线�E�和�U�程池分�z�֙�相连�Ӟ��Completion Handler自然可占先。但是，当与后反应式Completion Dispatcher相连�Ӟ��Completion Handler�q�没有对其他Completion Handler的占先权。当由Call-through分派器驱动时�Q�Completion Handler相对于在可报警等待状态的�U�程控制也没有占先权�?/div>
一般而言�Q�处理器不应该执行持�l�时间长的同步操作，除非使用了多个完成线�E�，因�ؓ应用的��M��响应性将会被显著地降低。这��L��危险可以通过增强的编�E�训�l�来降低。例如，所有Completion Handler被要求用作Proactive Initiator�Q�而不是去执行同步操作�?/div>
　
8.8 �C�Z��代码
　
�q�一部分昄��怎样使用前摄器模式来开发Web服务器。该例子��Z��ACE构架[4]中的前摄器实现�?/div>
当客戯��接到Web服务器时�Q�HTTP_Handler的open�Ҏ��被调用。于是服务器��通过在Asynchronous Operation完成时回调的对象�Q�在此例中是this指针�Q�、用于传输数据的�|�络�q�接�Q�以及一旦操作完成时使用的Completion Dispatcher�Q�proactor_�Q�来初始化异步I/O对象。随后读操作异步地启动，而服务器�q�回事�g循环�?/div>
当Async read操作完成�Ӟ��分派器回调HTTP_Handler::handle_read_stream。如果有��_��的数据，客户��h��p��解析。如果整个客戯��求还未完全到达，另一个读操作��׃��被异步地发�v�?/div>
在对GET��h��的响应中�Q�服务器�Ҏ��h��文�g�q�行内存映射�Q��ƈ��文件数据异步地写往客户。当写操作完成时�Q�分�z�֙�回调HTTP_Handler::handle_write_stream�Q�从而释攑֊�态分配的资源�?/div>
附录中含有两个其他的代码实例�Q��用同步的�U�程模型和同步的�Q�非��d��Q�反应式模型实现Web服务器�?/div>
　
class HTTP_Handler
: public Proactor::Event_Handler
// = TITLE
// Implements the HTTP protocol
// (asynchronous version).
//
// = PATTERN PARTICIPANTS
// Proactive Initiator = HTTP_Handler
// Asynch Op = Network I/O
// Asynch Op Processor = OS
// Completion Dispatcher = Proactor
// Completion Handler = HTPP_Handler
{
public:
void open (Socket_Stream *client)
{
// Initialize state for request
request_.state_ = INCOMPLETE;
　
// Store reference to client.
client_ = client;
　
// Initialize asynch read stream
stream_.open (*this, client_->handle (), proactor_);
　
// Start read asynchronously.
stream_.read (request_.buffer (),
request_.buffer_size ());
}
　
// This is called by the Proactor
// when the asynch read completes
void handle_read_stream(u_long bytes_transferred)
{
if (request_.enough_data(bytes_transferred))
parse_request ();
else
// Start reading asynchronously.
stream_.read (request_.buffer (),
　
request_.buffer_size ());
}
　
void parse_request (void)
{
// Switch on the HTTP command type.
switch (request_.command ())
{
// Client is requesting a file.
case HTTP_Request::GET:
// Memory map the requested file.
file_.map (request_.filename ());
　
// Start writing asynchronously.
stream_.write (file_.buffer (), file_.buffer_size ());
break;
　
// Client is storing a file
// at the server.
case HTTP_Request::PUT:
// ...
}
}
　
void handle_write_stream(u_long bytes_transferred)
{
if (file_.enough_data(bytes_transferred))
// Success....
else
// Start another asynchronous write
stream_.write (file_.buffer (), file_.buffer_size ());
}
　
private:
// Set at initialization.
Proactor *proactor_;
　
// Memory-mapped file_;
Mem_Map file_;
　
// Socket endpoint.
Socket_Stream *client_;
　
// HTTP Request holder
HTTP_Request request_;
　
// Used for Asynch I/O
Asynch_Stream stream_;
};
　
8.9 已知应用
　
下面是一些被�q�泛记蝲的前摄器的��用：
　
Windows NT中的I/O完成端口�Q?/b>Windows NT操作�pȝ��实现了前摄器模式。Windows NT支持多种Asynchronous Operation�Q�比如接受新�|�络�q�接、读写文件和socket�Q�以及通过�|�络�q�接传输文�g。操作系�l�就是Asynchronous Operation Processor。操作结果在I/O完成端口�Q�它扮演Completion Dispatcher的角�Ԍ��上排队�?/div>
　
异步I/O操作的UNIX AIO族：在有些实时POSIX�q�_��上，前摄器模式是由aio API族[9]来实现的。这些OS�Ҏ��非常类��g��上面描述的Windows NT的特性。一个区别是UNIX信号可用于实现真正异步的Completion Dispatcher�Q�Windows NT API不是真正异步的）�?/div>
　
ACE Proactor�Q?/b>ACE自适配通信环境 [4]实现了前摄器�l��g�Q�它��装Windows NT上的I/O完成端口�Q�以及POSIX�q�_��上的aio API。ACE前摄器抽象提供Windows NT所支持的标准C API的OO接口。这一实现的源码可从ACE�|�站http://www.cs.wustl.edu/~schmidt/ACE.html获取�?/div>
　
Windows NT中的异步�q�程调用�Q�Asynchronous Procedure Call�Q�：有些�pȝ��Q�比如Windows NT�Q�支持异步过�E�调用（APC�Q�。APC是在特定�U�程的上下文中异步执行的函数。当APC被排队到�U�程�Ӟ��pȝ��发出软�g中断。下一�ơ线�E�被调度�Ӟ��它将�q�行该APC。操作系�l�所发出的APC被称�?i>内核模式APC。应用所发出的APC被称�?i>用户模式APC�?/div>
　
8.10 相关模式
　
�?-9演示与前摄器相关的模式�?/div>
　
500)this.style.width=500;" border="0" />
　
�?-9 前摄器模式的相关模式
　
异步完成令牌�Q�ACT�Q�模式[8]通常与前摄器模式�l�合使用。当Asynchronous Operation完成�Ӟ��应用可能需要比��单的通知更多的信息来适当地处理事件。异步完成��o牌模式允许应用将状态高效地与Asynchronous Operation的完成相兌��?/div>
前摄器模式还与观察者（Observer�Q�模式[12]�Q�在其中�Q�当单个主题变动�Ӟ��相关对象也会自动更新�Q�有兟뀂在前摄器模式中�Q�当来自多个来源的事件发生时�Q�处理器被自动地通知。一般而言�Q�前摄器模式被用于异步地��多个输入源多�\分离�l�与它们相关联的事�g处理器，而观察者通常仅与单个事�g源相兌��?/div>
前摄器模式可被认为是同步反应堆模式[5]的一�U?i>异步�?/i>变体。反应堆模式负责多个事�g处理器的多�\分离和分�z�；它们在可�?i>同步地发�?/i>操作而不会阻塞时被触发。相反，前摄器模式也支持多个事�g处理器的多�\分离和分�z�，但它们是�?i>异步事�g的完�?/i>触发的�?/div>
��d��对象�Q�Active Object�Q�模式[13]使方法执行与�Ҏ��调用去耦合。前摄器模式也是�c�M��的，因�ؓAsynchronous Operation Processor代表应用的Proactive Initiator来执行操作。就是说�Q�两�U�模式都可用于实现Asynchronous Operation。前摄器模式常常用于替代��d��对象模式�Q�以使系�l��ƈ发策略与�U�程模型去耦合�?/div>
前摄器可被实��Cؓ单体�Q�Singleton�Q�[12]。这对于在异步应用中�Q�将事�g多�\分离和完成分�z�N��中到单一的地�Ҏ��说是有用的�?/div>
责�Q链（Chain of Responsibility�Q�COR�Q�模式[12]使事件处理器与事件源去耦合。在Proactive Initiator与Completion Handler的隔��M��Q�前摄器模式也是�c�M��的。但是，在COR中，事�g源预先不知道哪一个处理器��被执行�Q�如果有的话�Q�。在前摄器中�Q�Proactive Initiator完全知道目标处理器。但是，通过建立一个Completion Handler�Q�它是由外部工厂动态配�|�的责�Q铄��入口�Q�，�q�两�U�模式可被结合在一��P��?/div>
　
8.11 �l�束�?/b>
　
前摄器模式包含了一�U�强大的设计范式�Q�支持高性能�q�发应用的高效而灵�zȝ��事�g分派�{�略。前摄器模式提供�q�发执行操作的性能助益�Q�而又不强�q�开发者��用同步多�U�程或反应式�~�程�?/div>
　
参考文�?/b>
　
[1] J. Hu, I. Pyarali, and D. C. Schmidt, “Measuring the Impact of Event Dispatching and Concurrency Models on Web Server Performance Over High-speed Networks,�?in Proceedings of the 2^nd Global Internet Conference, IEEE, November 1997.
[2] J. Hu, I. Pyarali, and D. C. Schmidt, “Applying the Proactor Pattern to High-Performance Web Servers,�?in Proceedings of the 10th International Conference on Parallel and Distributed Computing and Systems, IASTED, Oct. 1998.
[3] J. C. Mogul, “The Case for Persistent-connection HTTP,�?in Proceedings of ACMSIGCOMM �?5 Conference in Computer Communication Review, (Boston, MA, USA), pp. 299�?14, ACM Press, August 1995.
[4] D. C. Schmidt, “ACE: an Object-Oriented Framework for Developing Distributed Applications,�?in Proceedings of the 6^th USENIX C++ Technical Conference, (Cambridge, Massachusetts), USENIX Association, April 1994.
[5] D. C. Schmidt, “Reactor: An Object Behavioral Pattern for Concurrent Event Demultiplexing and Event Handler Dispatching,�?in Pattern Languages of Program Design (J. O. Coplien and D. C. Schmidt, eds.), pp. 529�?45, Reading, MA: Addison-Wesley, 1995.
[6] D. C. Schmidt, “Acceptor and Connector: Design Patterns for Initializing Communication Services,�?in Pattern Languages of Program Design (R. Martin, F. Buschmann, and D. Riehle, eds.), Reading, MA: Addison-Wesley, 1997.
[7] M. K. McKusick, K. Bostic, M. J. Karels, and J. S. Quarterman, The Design and Implementation of the 4.4BSD Operating System. Addison Wesley, 1996.
[8] I. Pyarali, T. H. Harrison, and D. C. Schmidt, “Asynchronous Completion Token: an Object Behavioral Pattern for Efficient Asynchronous Event Handling,�?in Pattern Languages of Program Design (R. Martin, F. Buschmann, and D. Riehle, eds.), Reading, MA: Addison-Wesley, 1997.
[9] “Information Technology �?Portable Operating System Interface (POSIX) �?Part 1: System Application: Program Interface (API) [C Language],�?1995.
[10] Microsoft Developers Studio, Version 4.2 - Software Development Kit, 1996.
[11] E. W. Dijkstra, “Hierarchical Ordering of Sequential Processes,�?Acta Informatica, vol. 1, no. 2, pp. 115�?38, 1971.
[12] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.
[13] R. G. Lavender and D. C. Schmidt, “Active Object: an Object Behavioral Pattern for Concurrent Programming,�?in Proceedings of the 2^nd Annual Conference on the Pattern Languages of Programs, (Monticello, Illinois), pp. 1�?, September 1995.
　
附录A 可选实�?/b>
　
本附录概�q�用于开发前摄器模式的可选实现的代码。下面，我们��查��用多�U�程的同步I/O和��用单�U�程的反应式I/O�?/div>
　
A.1 多个同步�U�程
　
下面的代码显�C�怎样使用�U�程池同步I/O来开发Web服务器。当客户�q�接到服务器�Ӟ��池中的一个线�E�接受连接，�q�调用HTTP_Handler中的open�Ҏ��。随后服务器同步��C��|�络�q�接��d��h��。当��L��作完成时�Q�客戯��求随之被解析。在对GET��h��的响应中�Q�服务器�Ҏ��h��文�g�q�行内存映射�Q��ƈ��文件数据同步地写往客户。注意阻塞I/O是怎样使Web服务器能够遵�?.2.1中所概述的步骤的�?/div>
　
class HTTP_Handler
// = TITLE
// Implements the HTTP protocol
// (synchronous threaded version).
//
// = DESCRIPTION
// This class is called by a
// thread in the Thread Pool.
{
public:
void open (Socket_Stream *client)
{
HTTP_Request request;
　
// Store reference to client.
client_ = client;
　
// Synchronously read the HTTP request
// from the network connection and
// parse it.
client_->recv (request);
parse_request (request);
}
　
void parse_request (HTTP_Request &request)
{
// Switch on the HTTP command type.
switch (request.command ())
{
// Client is requesting a file.
case HTTP_Request::GET:
// Memory map the requested file.
Mem_Map input_file;
input_file.map (request.filename());
　
// Synchronously send the file
// to the client. Block until the
// file is transferred.
client_->send (input_file.data (),
input_file.size ());
break;
　
// Client is storing a file at
// the server.
case HTTP_Request::PUT:
// ...
}
}
　
private:
// Socket endpoint.
Socket_Stream *client_;
　
// ...
};
　
A.2 单线�E�反应式事�g分派
　
下面的代码显�C�怎样��反应堆模式用于开发Web服务器。当客户�q�接到服务器�Ӟ��HTTP_Handler::open�Ҏ��被调用。服务器登记I/O句柄和在�|�络句柄“读��q�A“时回调的对象（在此例中是this指针�Q�。然后服务器�q�回事�g循环�?/div>
当请求数据到达服务器�Ӟ��reactor_回调HTTP_Handler::handle_input�Ҏ��。客��h��据以非阻塞方式被��d��。如果有��_��的数据，客户��h��p��解析。如果整个客戯��求还没有到达�Q�应用就�q�回反应堆事件��@环�?/div>
在对GET��h��的响应中�Q�服务器�Ҏ��h��的文件进行内存映��；�q�在反应堆上登记�Q�以在网�l�连接变为“写��q�A”时被通知。当向连接写入数据不会阻塞调用线�E�时�Q�reactor_��回调HTTP_Handler::handler_output�Ҏ��。当所有数据都已发送给客户�Ӟ��|�络�q�接被关闭�?/div>
　
class HTTP_Handler :
public Reactor::Event_Handler
// = TITLE
// Implements the HTTP protocol
// (synchronous reactive version).
//
// = DESCRIPTION
// The Event_Handler base class
// defines the hooks for
// handle_input()/handle_output().
//
// = PATTERN PARTICIPANTS
// Reactor = Reactor
// Event Handler = HTTP_Handler
{
public:
void open (Socket_Stream *client)
{
// Initialize state for request
request_.state_ = INCOMPLETE;
　
// Store reference to client.
client_ = client;
　
// Register with the reactor for reading.
reactor_->register_handler
(client_->handle (),
this,
Reactor::READ_MASK);
}
　
// This is called by the Reactor when
// we can read from the client handle.
void handle_input (void)
{
int result = 0;
　
// Non-blocking read from the network
// connection.
do
result = request_.recv (client_->handle ());
while (result != SOCKET_ERROR && request_.state_ == INCOMPLETE);
　
// No more progress possible,
// blocking will occur
if (request_.state_ == INCOMPLETE && errno == EWOULDBLOCK)
reactor_->register_handler
(client_->handle (),
this,
Reactor::READ_MASK);
else
// We now have the entire request
parse_request ();
}
　
void parse_request (void)
{
// Switch on the HTTP command type.
switch (request_.command ())
{
// Client is requesting a file.
case HTTP_Request::GET:
　
// Memory map the requested file.
file_.map (request_.filename ());
　
// Transfer the file using Reactive I/O.
handle_output ();
break;
　
// Client is storing a file at
// the server.
case HTTP_Request::PUT:
// ...
}
}
　
void handle_output (void)
{
// Asynchronously send the file
// to the client.
if (client_->send (file_.data (),
file_.size ())
== SOCKET_ERROR
&& errno == EWOULDBLOCK)
// Register with reactor...
else
// Close down and releas
resources.
handle_close ();
}
　
private:
// Set at initialization.
Reactor *reactor_;
　
// Memory-mapped file_;
Mem_Map file_;
　
// Socket endpoint.
Socket_Stream *client_;
　
// HTTP Request holder.
HTTP_Request request_;
};

本文转蝲至ACE开发者网�?作者：Irfan Pyarali Tim Harrison

walkspeed 2007-02-27 21:17 发表评论

ACE中网�l�通讯�~�程基本架构

walkspeed — Sun, 25 Feb 2007 11:30:00 GMT

    ACE_INET_Addr�c�，包装了网�l�地址
    ACE_SOCK_Connector�c�，扮演��d��q�接角色�Q�发起通讯�q�接。连接到�q�端的服务�?br />    ACE_SOCK_Acceptor�c�，扮演被动�q�接角色�Q�等待连接。等待远端客��L��h��?br />    ACE_SOCK_Stream�c�，扮演数据通讯角色�Q�发送和接收数据。完成客户与服务之间的通讯�?br />
    利用ACE库来开发网�l�通讯�E�序是很��单的�Q�一个基本程序只用到以上提到的几个类�Q�就
可以完成一个基于客��L��、服务器端模型的�|�络应用的开发。开发者无需了解Socket在不同��^
��C��的实玎ͼ�记忆众多�q�相互关联的Socket APIs�?/p>
    一下以一个Hello World�E�序为演�C��?br />
    客户端程序。发送一个Hello World到远端的服务器，�q�接收服务器�q�回的信息，��信�?br />打印在屏�q�上�?/p>
#include
#include

#include
#include
#include
#include

int main( int argc, char* argv[] )
{
ACE::init();//初始化ACE库，在windows下一定要

std::string str = "hello world";

//讄��服务器地址
//�W�一个参数是端口�Q�第二个是ip地址�Q�也可以是域名�?br /> //可以先定义一个地址对象�Q�再用ACE_INET_Addr的set函数来设定�?br /> //地址的配�|�很多，具体的参照文�?br /> ACE_INET_Addr peer_addr( 5050, "127.0.0.1" );
ACE_SOCK_Stream peer_stream;//定义一个通讯队�Ş

ACE_SOCK_Connector peer_connector;//定义一个主动连接对�?br /> peer_connector.connect( peer_stream, peer_addr );//发�v一个连�?/p>
peer_stream.send( str.c_str(), str.length() );//发送数据到服务�?/p>
str.erase();
str.resize( sizeof( "hello world" ) );
peer_stream.recv( (void*)str.c_str(), str.length() );//接收来自服务器的信息

std::cout << "from server message : " << str << std::endl;

    ACE::fini();
return 0;
}

    服务器端代码。接收一个远端的�q�接�Q�将接收到的信息打印在屏�q�上�Q��ƈ��接收到的信
息返回给客户端�?br />#include
#include

#include
#include
#include

int main( int argc, char* argv[] )
{
ACE::init();

std::string str;
str.resize( sizeof( "hello world" ) );

//讄��服务器地址
ACE_INET_Addr peer_addr( 5050, "127.0.0.1" );

ACE_SOCK_Stream peer_stream;

//创徏被动�q�接角色对象
ACE_SOCK_Acceptor peer_acceptor;
//开启被动连接对象，��对象绑定到一个地址�?br /> peer_acceptor.open( peer_addr );

//�{�待�q�接
peer_acceptor.accept( peer_stream );

//数据通讯
peer_stream.recv( (void*)str.c_str(), str.length() );
std::cout << "from client message : " << str << std::endl;
peer_stream.send( str.c_str(), str.length() );

ACE::fini();
return 0;
}
××××以上代码需要ACE库才能运转×××�?br />
    利用ACE�~�程的基本框架�?br />    客户�?br />    1 创徏地址对象。（ACE_INET_Addr�Q?br />    2 创徏��d��q�接对象。（ACE_SOCK_Connector�Q?br />    3 创徏数据通讯对象。（ACE_SOCK_Stream�Q?br />    4 讄��服务器地址。（ACE_INET_Addr::set�Q?br />    5 ��数据通讯对象和地址作�ؓ参数传给��d��q�接对象�Q�发起主动连接（ACE_SOCK_Connector::connect�Q?br />    6 利用通讯对象接收和发送数据。（ACE_SOCK_Stream::recv和ACE_SOCK_Stream::send�Q?br />
    服务器端
    1 创徏地址对象。（ACE_INET_Addr�Q?br />    2 创徏被动�q�接对象。（ACE_SOCK_Connector�Q?br />    3 创徏数据通讯对象。（ACE_SOCK_Stream�Q?br />    4 讄��服务器地址。（ACE_INET_Addr::set�Q?br />    5 ��地址作�ؓ参数传给被动�q�接对象�Q�启动接�Ӟ��ACE_SOCK_Acceptor::open�Q?br />    6 ��数据通讯对象传给被动�q�接对象�Q�启动接�Ӟ��接受�q�接�Q�ACE_SOCK_Connector::accept�Q?br />    7 利用通讯对象接收和发送数据。（ACE_SOCK_Stream::recv和ACE_SOCK_Stream::send�Q?/p>

walkspeed 2007-02-25 19:30 发表评论

ACE中Socket IPC通讯包装�c�L��

walkspeed — Sat, 24 Feb 2007 06:15:00 GMT

    ACE_IPC_SAP�c�L��IPC�c�L��的基�c�，��装了句柄，提供了访问句柄的基本接口�Q�基本结�?br />如下
class ACE_IPC_SAP
{
public:
int enable (int value) const;
int disable (int value) const;

ACE_HANDLE get_handle (void) const;
void set_handle (ACE_HANDLE handle);

protected:
ACE_IPC_SAP (void);
~ACE_IPC_SAP (void);

private:
ACE_HANDLE handle_;
};

    ACE_SOCK�c�L��使用Socket的基�c�，所有��用Socket通讯的类都从�q�个�c�L��生。本�cȝ��?br />能包�?br />    1 创徏和销毁Socket句柄
    2 获取本地和远端的�|�络地址
    3 讄��和读取Socket选项�?br />基本�l�构如下
class ACE_SOCK : public ACE_IPC_SAP
{
public:
//讄��Socket的属性，包装了setsockopt�pȝ��函数
int set_option (int level,
                  int option,
                  void *optval,
                  int optlen) const;
//获取Socket的属性，包装了getsockopt�pȝ��函数
int get_option (int level,
                  int option,
                  void *optval,
                  int *optlen) const;
//获得本地地址
int get_local_addr (ACE_Addr &) const;
//获取�q�端地址
int get_remote_addr (ACE_Addr &) const;
//关闭Socket
int close (void);
//打开一个Socket�Q�没有Qos
int open (int type,
            int protocol_family,
            int protocol,
            int reuse_addr);
//打开一个Socket�Q�有Qos
int open (int type,
            int protocol_family,
            int protocol,
            ACE_Protocol_Info *protocolinfo,
            ACE_SOCK_GROUP g,
            u_long flags,
            int reuse_addr);

protected:
ACE_SOCK (int type,
            int protocol_family,
            int protocol = 0,
            int reuse_addr = 0);
ACE_SOCK (int type,
            int protocol_family,
            int protocol,
            ACE_Protocol_Info *protocolinfo,
            ACE_SOCK_GROUP g,
            u_long flags,
            int reuse_addr);
ACE_SOCK (void);
~ACE_SOCK (void);
};

    ACE_SOCK_IO�c�，包装了Socket数据通讯的基本方法。本�c�L��供的功能
    1 支持数据的发送和接收
    2 支持分散��L��?br />    3 支持集中写操�?br />    4 支持��d��Q�非��d��Q�定�?I/O操作
基本�l�构如下
class ACE_SOCK_IO : public ACE_SOCK
{
public:
ACE_SOCK_IO (void);
~ACE_SOCK_IO (void);

//接收数据
ssize_t recv (void *buf,
                size_t n,
                const ACE_Time_Value *timeout = 0) const;
//分散��L��?br /> ssize_t recv (iovec iov[],
                size_t n,
                const ACE_Time_Value *timeout = 0) const;
//发送数据            �?
ssize_t send (const void *buf,
                size_t n,
                const ACE_Time_Value *timeout = 0) const;
//集中写操�?br /> ssize_t send (const iovec iov[],
                size_t n,
                const ACE_Time_Value *timeout = 0) const;
};

    ACE_SOCK_Stream�c�，�l�承ACE_SOCK_IO�c�R��在ACE_SOCK_IO�c�L��供的功能上，��d��了发�?br />和接收刚好n个字节的能力。基本结构如�?br />class ACE_Export ACE_SOCK_Stream : public ACE_SOCK_IO
{
public:
ACE_SOCK_Stream (void);
ACE_SOCK_Stream (ACE_HANDLE h);
~ACE_SOCK_Stream (void);

//刚好��d��n个字节的数据
ssize_t recv_n (void *buf,
                  size_t len,
                  const ACE_Time_Value *timeout = 0,
                  size_t *bytes_transferred = 0) const;
//分散��d��好n个字节操�?br /> ssize_t recvv_n (iovec iov[],
                   int iovcnt,
                   const ACE_Time_Value *timeout = 0,
                   size_t *bytes_transferred = 0) const;
//刚好发送n个字节的数据
ssize_t send_n (const void *buf,
                  size_t len,
                  const ACE_Time_Value *timeout = 0,
                  size_t *bytes_transferred = 0) const;
//集中写刚好n个字节操�?br /> ssize_t sendv_n (const iovec iov[],
                   int iovcnt,
                   const ACE_Time_Value *timeout = 0,
                   size_t *bytes_transferred = 0) const;

int close_reader (void);
int close_writer (void);

int close (void);

typedef ACE_INET_Addr PEER_ADDR;
};

    ACE_SOCK_Acceptor�c�L��一个工厂类�Q�用来被动��生一个新的通讯端点。提供如下能�?br />    1 接收对等端的�q�接
    2 �q�接可以通过��d��、非��d��或定时方式接受�?br />基本�l�构如下
class ACE_Export ACE_SOCK_Acceptor : public ACE_SOCK
{
public:

ACE_SOCK_Acceptor (void);
ACE_SOCK_Acceptor (const ACE_Addr &local_sap,
                     int reuse_addr = 0,
                     int protocol_family = PF_UNSPEC,
                     int backlog = ACE_DEFAULT_BACKLOG,
                     int protocol = 0);
~ACE_SOCK_Acceptor (void);

//打开一个监�?br /> int open (const ACE_Addr &local_sap,
            int reuse_addr = 0,
            int protocol_family = PF_UNSPEC,
            int backlog = ACE_DEFAULT_BACKLOG,
            int protocol = 0);

int close (void);
//接受一个对�{�端的连接，产生一个通讯
int accept (ACE_SOCK_Stream &new_stream,
              ACE_Addr *remote_addr = 0,
              ACE_Time_Value *timeout = 0,
              int restart = 1,
              int reset_new_handle = 0) const;
};

    ACE_SOCK_Connector�c�L��一个工厂类�Q�用来主动徏立一个新的通讯端。提供的功能如下
    1 发�v一个到对等接受者的�q�接�Q��ƈ在连接后产生一个通讯对象
    2 �q�接可以通过��d��、非��d��或定时方式发�?br />基本�l�构如下
class ACE_SOCK_Connector
{
public:
ACE_SOCK_Connector (void);
ACE_SOCK_Connector (ACE_SOCK_Stream &new_stream,
                      const ACE_Addr &remote_sap,
                      const ACE_Time_Value *timeout = 0,
                      const ACE_Addr &local_sap = ACE_Addr::sap_any,
                      int reuse_addr = 0,
                      int flags = 0,
                      int perms = 0,
                      int protocol = 0);

//发�v一个连�?br /> int connect (ACE_SOCK_Stream &new_stream,
               const ACE_Addr &remote_sap,
               const ACE_Time_Value *timeout = 0,
               const ACE_Addr &local_sap = ACE_Addr::sap_any,
               int reuse_addr = 0,
               int flags = 0,
               int perms = 0,
               int protocol = 0);

~ACE_SOCK_Connector (void);

int complete (ACE_SOCK_Stream &new_stream,
                ACE_Addr *remote_sap = 0,
                const ACE_Time_Value *timeout = 0);
};

    以上的类�l�构是简化的�Q�以�H�出重点功能。要完全了解每个�c�，看源代码�?/p>

walkspeed 2007-02-24 14:15 发表评论

ACE_WFMO_Reactor多�\分配��d��部分��结

walkspeed — Thu, 22 Feb 2007 03:46:00 GMT

    多�\分配的入口函数handle_events�Q�在框架的实现接口类中定�?br />    多�\分配的主体实现函数event_handling,在ACE_WFMO_Reactor中定义，�?br />实现代码如下
int ACE_WFMO_Reactor::event_handling (ACE_Time_Value *max_wait_time,
                                      int alertable)
{
int result = 0;

do
{
      //�{�待在句柄集上发生的事�g
      //wait_for_multiple_events的具体实现是使用
      //WaitForMultipleObjectsEx函数
      DWORD wait_status = this->wait_for_multiple_events (timeout,
                                                          alertable);
      //分发事�g
      result = this->safe_dispatch (wait_status);
}while (result == 0);

return result;
}

    分发的主体函数是dispatch_handles,在ACE_WFMO_Reactor中定义，伪实�?br />代码如下
int ACE_WFMO_Reactor::dispatch_handles (DWORD wait_status)
{
DWORD dispatch_slot = 0;

//�z�d��的句柄��L��
DWORD max_handlep1 = this->handler_rep_.max_handlep1 ();

//查找要分发的句柄的烦�?br /> for (int number_of_handlers_dispatched = 1;;++number_of_handlers_dispatched)
{
      //计算有事件发生，要分发的句柄索引
      dispatch_slot += wait_status - WAIT_OBJECT_0;
      //分发�l�相应的事�g处理对象
      if (this->dispatch_handler (dispatch_slot, max_handlep1) == -1)
        return -1;

      ++dispatch_slot;

      if (dispatch_slot >= max_handlep1)
        return number_of_handlers_dispatched;//分发了几个事�?/p>
      //��查剩下的句柄中有没有有事件发生的
      wait_status = this->poll_remaining_handles (dispatch_slot);
      switch (wait_status)
      {
        case WAIT_FAILED: // Failure.
          ACE_OS::set_errno_to_last_error ();
          /* FALLTHRU */
        case WAIT_TIMEOUT:
          // There are no more handles ready, we can return.
          return number_of_handlers_dispatched;//分发了几个事�?br />      }
}
}

    扑ֈ�具体事�g处理对象��M��函数complex_dispatch_hander,在ACE_WFMO_Reactor
中定义，��Z��码如�?br />int ACE_WFMO_Reactor::complex_dispatch_handler (DWORD slot,
                                                ACE_HANDLE event_handle)
{
//扑ֈ�当前的分发的信息
ACE_WFMO_Reactor_Handler_Repository::Current_Info ¤t_info =
    this->handler_rep_.current_info ()[slot];

WSANETWORKEVENTS events;
ACE_Reactor_Mask problems = ACE_Event_Handler::NULL_MASK;
if (::WSAEnumNetworkEvents ((SOCKET) current_info.io_handle_,
                              event_handle,
                              &events) == SOCKET_ERROR)
    problems = ACE_Event_Handler::ALL_EVENTS_MASK;
else
{
      //发生的事件于要检��的事�g是否相同�Q�相同就分发
      events.lNetworkEvents &= current_info.network_events_;
      while (events.lNetworkEvents != 0)
      {
          ACE_Event_Handler *event_handler = current_info.event_handler_;

          //调用事�g处理对象�Q�进行事件处�?br />          problems |= this->upcall (current_info.event_handler_,
                                    current_info.io_handle_,
                                    events);

          if (this->handler_rep_.scheduled_for_deletion (slot))
            break;
      }
}

return 0;
}

walkspeed 2007-02-22 11:46 发表评论

walkspeed — Thu, 22 Feb 2007 02:54:00 GMT

1
int ACE_WFMO_Reactor::handle_events (ACE_Time_Value &how_long)
{
return this->event_handling (&how_long, FALSE);
}

2
// Waits for and dispatches all events. Returns -1 on error, 0 if
// max_wait_time expired, or the number of events that were dispatched.
int ACE_WFMO_Reactor::event_handling (ACE_Time_Value *max_wait_time,
                                      int alertable)
{
ACE_TRACE ("ACE_WFMO_Reactor::event_handling");

// Make sure we are not closed
if (!this->open_for_business_ || this->deactivated_)
      return -1;

// Stash the current time -- the destructor of this object will
// automatically compute how much time elapsed since this method was
// called.
ACE_Countdown_Time countdown (max_wait_time);

int result;

do
{
      // Check to see if it is ok to enter ::WaitForMultipleObjects
      // This will acquire lock_> on success On failure, the
      // lock will not be acquired

      result = this->ok_to_wait (max_wait_time, alertable);
      if (result != 1)
        return result;

      // Increment the number of active threads
      ++this->active_threads_;

      // Release the
      this->lock_.release ();

      // Update the countdown to reflect time waiting to play with the
      // mut and event.

      countdown.update ();

      // Calculate timeout
      int timeout = this->calculate_timeout (max_wait_time);

      // Wait for event to happen
      DWORD wait_status = this->wait_for_multiple_events (timeout,
                                                          alertable);

      // Upcall
      result = this->safe_dispatch (wait_status);
      if (0 == result)
      {
          // wait_for_multiple_events timed out without dispatching
          // anything. Because of rounding and conversion errors and
          // such, it could be that the wait loop timed out, but
          // the timer queue said it wasn't quite ready to expire a
          // timer. In this case, max_wait_time won't have quite been
          // reduced to 0, and we need to go around again. If max_wait_time
          // is all the way to 0, just return, as the entire time the
          // caller wanted to wait has been used up.
          countdown.update ();     // Reflect time waiting for events

          if (0 == max_wait_time || max_wait_time->usec () == 0)
            break;
      }
}while (result == 0);

return result;
}

3
int ACE_WFMO_Reactor::safe_dispatch (DWORD wait_status)
{
int result = -1;
ACE_SEH_TRY
{
      result = this->dispatch (wait_status);
}
ACE_SEH_FINALLY
{
      this->update_state ();
}

return result;
}

4
int ACE_WFMO_Reactor::dispatch (DWORD wait_status)
{
int handlers_dispatched = 0;

// Expire timers
handlers_dispatched += this->expire_timers ();

switch (wait_status)
{
case WAIT_FAILED: // Failure.
      ACE_OS::set_errno_to_last_error ();
      return -1;

case WAIT_TIMEOUT: // Timeout.
      errno = ETIME;
      return handlers_dispatched;

default: // Dispatch.
      // We'll let dispatch worry about abandoned mutes.
      handlers_dispatched += this->dispatch_handles (wait_status);
      return handlers_dispatched;
}
}

5
// Dispatches any active handles from to
// , polling through our handle set looking
// for active handles.

int ACE_WFMO_Reactor::dispatch_handles (DWORD wait_status)
{
// dispatch_slot is the absolute slot. Only += is used to
// increment it.
DWORD dispatch_slot = 0;

// Cache this value, this is the absolute value.
DWORD max_handlep1 = this->handler_rep_.max_handlep1 ();

// nCount starts off at , this is a transient count of
// handles last waited on.
DWORD nCount = max_handlep1;

for (int number_of_handlers_dispatched = 1;;++number_of_handlers_dispatched)
{
      const bool ok = (wait_status >= WAIT_OBJECT_0 && wait_status <= (WAIT_OBJECT_0 + nCount));

      if (ok)
        dispatch_slot += wait_status - WAIT_OBJECT_0;
      else
        // Otherwise, a handle was abandoned.
        dispatch_slot += wait_status - WAIT_ABANDONED_0;

      // Dispatch handler
      if (this->dispatch_handler (dispatch_slot, max_handlep1) == -1)
        return -1;

      // Increment slot
      ++dispatch_slot;

      // We're done.
      if (dispatch_slot >= max_handlep1)
        return number_of_handlers_dispatched;

      // Readjust nCount
      nCount = max_handlep1 - dispatch_slot;

      // Check the remaining handles
      wait_status = this->poll_remaining_handles (dispatch_slot);
      switch (wait_status)
      {
        case WAIT_FAILED: // Failure.
          ACE_OS::set_errno_to_last_error ();
          /* FALLTHRU */
        case WAIT_TIMEOUT:
          // There are no more handles ready, we can return.
          return number_of_handlers_dispatched;
      }
}
}

6
int ACE_WFMO_Reactor::dispatch_handler (DWORD slot,
                                        DWORD max_handlep1)
{
// Check if there are window messages that need to be dispatched
if (slot == max_handlep1)
    return this->dispatch_window_messages ();

// Dispatch the handler if it has not been scheduled for deletion.
// Note that this is a very week test if there are multiple threads
// dispatching this slot as no locks are held here. Generally, you
// do not want to do something like deleting the this pointer in
// handle_close() if you have registered multiple times and there is
// more than one thread in WFMO_Reactor->handle_events().
else if (!this->handler_rep_.scheduled_for_deletion (slot))
{
      ACE_HANDLE event_handle = *(this->handler_rep_.handles () + slot);

      if (this->handler_rep_.current_info ()[slot].io_entry_)
        return this->complex_dispatch_handler (slot,
                                               event_handle);
      else
        return this->simple_dispatch_handler (slot,
                                              event_handle);
}
else
    // The handle was scheduled for deletion, so we will skip it.
    return 0;
}

7
int ACE_WFMO_Reactor::complex_dispatch_handler (DWORD slot,
                                                ACE_HANDLE event_handle)
{
// This dispatch is used for I/O entires.

ACE_WFMO_Reactor_Handler_Repository::Current_Info ¤t_info =
    this->handler_rep_.current_info ()[slot];

WSANETWORKEVENTS events;
ACE_Reactor_Mask problems = ACE_Event_Handler::NULL_MASK;
if (::WSAEnumNetworkEvents ((SOCKET) current_info.io_handle_,
                              event_handle,
                              &events) == SOCKET_ERROR)
    problems = ACE_Event_Handler::ALL_EVENTS_MASK;
else
{
      // Prepare for upcalls. Clear the bits from representing
      // events the handler is not interested in. If there are any left,
      // do the upcall(s). upcall will replace events.lNetworkEvents
      // with bits representing any functions that requested a repeat
      // callback before checking handles again. In this case, continue
      // to call back unless the handler is unregistered as a result of
      // one of the upcalls. The way this is written, the upcalls will
      // keep being done even if one or more upcalls reported problems.
      // In practice this may turn out not so good, but let's see. If any
      // problems, please notify Steve Huston <shuston@riverace.com>
      // before or after you change this code.
      events.lNetworkEvents &= current_info.network_events_;
      while (events.lNetworkEvents != 0)
      {
          ACE_Event_Handler *event_handler = current_info.event_handler_;

          int reference_counting_required =
            event_handler->reference_counting_policy ().value () ==
            ACE_Event_Handler::Reference_Counting_Policy::ENABLED;

          // Call add_reference() if needed.
          if (reference_counting_required)
          {
              event_handler->add_reference ();
          }

          // Upcall
          problems |= this->upcall (current_info.event_handler_,
                                    current_info.io_handle_,
                                    events);

          // Call remove_reference() if needed.
          if (reference_counting_required)
          {
              event_handler->remove_reference ();
          }

          if (this->handler_rep_.scheduled_for_deletion (slot))
            break;
      }
}

if (problems != ACE_Event_Handler::NULL_MASK
      && !this->handler_rep_.scheduled_for_deletion (slot) )
    this->handler_rep_.unbind (event_handle, problems);

return 0;
}

8
ACE_Reactor_Mask ACE_WFMO_Reactor::upcall (ACE_Event_Handler *event_handler,
                                           ACE_HANDLE io_handle,
                                           WSANETWORKEVENTS &events)
{
// This method figures out what exactly has happened to the socket
// and then calls appropriate methods.
ACE_Reactor_Mask problems = ACE_Event_Handler::NULL_MASK;

// Go through the events and do the indicated upcalls. If the handler
// doesn't want to be called back, clear the bit for that event.
// At the end, set the bits back to to request a repeat call.

long actual_events = events.lNetworkEvents;
int action;

if (ACE_BIT_ENABLED (actual_events, FD_WRITE))
{
      action = event_handler->handle_output (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_WRITE);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::WRITE_MASK);
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_CONNECT))
{
      if (events.iErrorCode[FD_CONNECT_BIT] == 0)
      {
          // Successful connect
          action = event_handler->handle_output (io_handle);
          if (action <= 0)
          {
              ACE_CLR_BITS (actual_events, FD_CONNECT);
              if (action == -1)
                ACE_SET_BITS (problems, ACE_Event_Handler::CONNECT_MASK);
          }
      }
      // Unsuccessful connect
      else
      {
          action = event_handler->handle_input (io_handle);
          if (action <= 0)
          {
              ACE_CLR_BITS (actual_events, FD_CONNECT);
              if (action == -1)
                ACE_SET_BITS (problems, ACE_Event_Handler::CONNECT_MASK);
          }
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_OOB))
{
      action = event_handler->handle_exception (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_OOB);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::EXCEPT_MASK);
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_READ))
{
      action = event_handler->handle_input (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_READ);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::READ_MASK);
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_CLOSE)
      && ACE_BIT_DISABLED (problems, ACE_Event_Handler::READ_MASK))
{
      action = event_handler->handle_input (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_CLOSE);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::READ_MASK);
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_ACCEPT))
{
      action = event_handler->handle_input (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_ACCEPT);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::ACCEPT_MASK);
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_QOS))
{
      action = event_handler->handle_qos (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_QOS);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::QOS_MASK);
      }
}

if (ACE_BIT_ENABLED (actual_events, FD_GROUP_QOS))
{
      action = event_handler->handle_group_qos (io_handle);
      if (action <= 0)
      {
          ACE_CLR_BITS (actual_events, FD_GROUP_QOS);
          if (action == -1)
            ACE_SET_BITS (problems, ACE_Event_Handler::GROUP_QOS_MASK);
      }
}

events.lNetworkEvents = actual_events;
return problems;
}

walkspeed 2007-02-22 10:54 发表评论

walkspeed — Tue, 20 Feb 2007 04:28:00 GMT
        ACE�q�个开源项目的代码的量是很大的。对于系�l�编�E�、网�l�编�E�是非常的有用，但是对其介绍的书和资料是非常的少。要想了解和很好的��用，��必��要自己�ȝ��源代码了。（好在�q�有三本书，库中的事例还是比较的多）
        ACE库中的代码大体可以分��Z��大部�?br />        1 OS Adaptation�Q�操作系�l�适配�Q�部分。这部分主要是屏蔽各操作�pȝ��的API的不同，��系�l�调用接口统一到C�Q�＋函数的接口，以实现��^台的可移植�?br />        2 C++ Wrapper Facade�Q�C++外包�Q�部分。这部分主要是将�怺�兌��的操作和数据�l�构��装到C++�c�M��Q�提供统一的接口。提供强�c�d��的检��，降低不必要的认�ؓ错误。利用C++多态、��承等能力�Q��Ş成一个架构，使本地的、远端的操作�l�一在一个相同接口和使用�{�略下�?br />        3 Framework�Q�框�Ӟ��部分。�ؓ一�l�相关的应用提供可复用的架构。开发者在��定了应用后�Q�选择可用的架构开发应用程序，不用考虑�q�_��和底层机制。快速的开发�?br />        �W�一部分面对大量的底层的�l�节�Q�而且目标是��^台的�U�L��Q�如果对�q�_��的移植感兴趣的兄弟姐妹可以看看。一般情况下没什么看的必要�?br />        �W�二部分和第三部分对我们的应用和学习如何利用C++来设计程序非常的有�h��|��要多看。细心揣摩，特别是配上设计的问题�Q�宏观的和微观的�Q��?img src ="http://www.shnenglu.com/walkspeed/aggbug/18876.html" width = "1" height = "1" />

walkspeed 2007-02-20 12:28 发表评论

�U�程模型	�pȝ��c�d��
�U�程模型	单处理器	多处理器
单线�E?/div>	A	B
多线�E?/div>	C	D

久久精品在这里,欧美在线影院,欧美高清在线

ACE的接受器�Q�Acceptor�Q�和�q�接器（Connector�Q�：�q�接建立模式

转蝲一片关于前摄器�Q�Proactor�Q�的文章

ACE中网�l�通讯�~�程基本架构

ACE中Socket IPC通讯包装�c�L��

ACE_WFMO_Reactor多�\分配��d��部分���结

ACE_WFMO_Reactor多�\分配��d��部分��结