有效使用反应堆Reactor的设计准则

　　ACE_Reactor是事件多路分离和事件处理器分派的强大构架。但是，像其他构 架一样，学习使用ACE_Reactor需要时间和努力。缩短学习曲线的的一种途径是去理解有效使用反应堆所必须遵从的设计准则。下面描述的设计准则基于 帮助ACE用户正确进行反应堆构架编程所获得的大量经验。
　
7.5.1 理解具体事件处理器的返回值语义
　
具体事件处理 器定义的各种handle_* 挂钩方法的返回值致使ACE_Reactor以不同的方式工作。使用返回值来触发不同行为意在降低ACE_Reactor的API的复杂度。但是，返回值 常常使得程序员莫明其妙。因而，理解从handle_* 方法返回的值的效应非常重要；这些值分为三种情况：
　
零：handle_* 方法返回零（0）通知ACE_Reactor、事件处理器希望继续像前面一样被处理，也就是，它应该保持在ACE_Reactor的实现的一张表中。这 样，当下一次ACE_Reactor的事件多路分离器系统调用经由handle_events被调用时，它还会继续包括该事件处理器的句柄。对于那些生存 期超出一次handle_* 方法分派的事件处理器，这是一种“正常的”行为。
　
大于零：handle_* 方法返回大于０（> 0）的值通知ACE_Reactor、事件处理器希望在ACE_Reactor阻塞在它的事件多路分离器系统调用上面之前，再一次被分派。对协作的事件处 理器来说，这种特性有助于增强全面的系统“公正性”。特别地，这种特性使得一个事件处理器在再次持有控制之前，允许其他事件处理器被分派。
　
小 于零：handle_* 方法返回小于０（< 0 ）的值通知ACE_Reactor、事件处理器想要被关闭、并从ACE_Reactor的内部表中移除。为完成此工作、ACE_Reactor调用事件处 理器的handle_close清扫方法。该方法可以执行用户定义的终止活动，比如删除对象分配的动态内存或关闭日志文件。handle_close方法 返回后，ACE_Reactor将相关联的具体事件处理器从它的内部表中移除。
　
为减少handle_* 返回值所带来的问题，在实现具体事件处理器时，遵守下面的设计准则：
　
设 计准则0：不要手工删除事件处理器对象或显式调用handle_close棗相反，确保ACE_Reactor自动调用handle_close清扫方 法。因而，应用必须遵从适当的协议来移除事件处理器，也就是，或者通过（1）从handle_* 挂钩方法中返回负值，或者通过（2）调用remove_handler。
该设计准则确保ACE_Reactor能够适当地清扫它的内部表。如果不 服从这一准则，当ACE_Reactor试图移除已经在外部被删除的具体事件处理器时，就会带来不可预测的内存管理问题。后面的设计准则详细说明怎样确保 ACE_Reactor调用handle_close清扫方法。
　
设计准则1：从继承自ACE_Event_Handler的类的 handle_* 方法中返回的表达式必须是常量（constant）。这一设计准则有助于静态地检查是否handle_* 方法返回了恰当的值。如果必须违反此准则，开发者必须在return语句之前加一注释，解释为何要使用变量，而不是常量。
　
设计准则2：如果从继承自ACE_Event_Handler的类的handle_* 方法中返回的值不为0，必须在return语句之前加一注释，说明该返回值的含义。这一设计准则确保所有非0的返回值都是开发者有意使用的。

7.5.2 理解handle_close()清扫挂钩的语义
　
必 须记住handle_close清扫挂钩方法只能由ACE_Reactor（1）隐式地调用，也就是，当handle_* 方法返回-1这样的负值时，或是（2）显式地调用，也就是，如果应用调用remove_handler方法来解除具体事件处理器的登记。特别地， ACE_Reactor不会在本地应用或是远地应用关闭I/O句柄时自动调用handle_close。因此，应用必须确定何时I/O句柄已被关闭，并采 取适当的步骤，以使ACE_Reactor触发handle_close清扫方法。
下面的来自7.4.2.2的Logging_Handler代码片段演示怎样正确地触发清扫挂钩：
　
// Hook method for handling the reception of
// remote logging transmissions from clients.
int Logging_Handler::handle_input (ACE_HANDLE)
{
ssize_t n = peer_stream_.recv (&len, sizeof len);
　
if (n == 0)
// Trigger handle_close().
return -1;
　
//..
　
// Keep handler registered for ‘‘normal’’ case.
return 0;
}
　
当handle_input方法从recv那里收到0，它就返回-1。该值触发ACE_Reactor调用handle_close清扫挂钩。
为最少化handle_* 返回值所带来的问题，在实现具体事件处理器时，应遵守下面的设计准则：
　
设 计准则3：当你想要触发具体事件处理器的相应handle_close清扫方法时，从handle_* 方法中返回一个负值。值-1通常用于触发清扫挂钩，因为它是ACE_OS系统调用包装中一个常用的错误代码。但是，任何来自handle_* 方法的负数都将触发handle_close。
　
设计准则4：将所有Event_Handler清扫活动限制在handle_close 清扫方法中。一般而言，将所有的清扫活动合并到handle_close方法中，而不是分散在事件处理器的各个handle_* 方法中要更为容易。在处理动态分配的、必须用delete this来清除的事件处理器时，特别需要遵从此设计准则（见准则9）。
　
7.5.3 记住ACE_Time_Value参数是相对的
　
传递给ACE_Reactor的schedule_timer方法的两个ACE_Time_Value参数必须相对于当前时间指定。例如，下面的代码调度一个对象，延迟delay秒后开始，每interval秒打印一次可执行程序的名字（也就是，argv[0]）：
　
class Hello_World : public ACE_Event_Handler
{
public:
virtual int handle_timeout (const ACE_Time_Value &tv, const void *act)
{
ACE_DEBUG ((LM_DEBUG,
"%[s] %d, %d/n",
act,
tv.sec (),
tv.usec ()));
return 0;
}
};
　
int main (int argc, char *argv[])
{
if (argc != 3)
ACE_ERROR_RETURN ((LM_ERROR,
"usage: %s delay interval/n",
argv[0]), -1);
　
Hello_World handler; // timer object.
　
ACE_Time_Value delay = ACE_OS::atoi (argv[1]);
ACE_Time_Value interval = ACE_OS::atoi (argv[2]);
　
// Schedule the timer.
ACE_Reactor::instance ()->schedule_timer
(&handler,
(const void *) argv[0],
delay,
interval);
　
// Run the event loop.
for (;;)
ACE_Reactor::instance ()->handle_events ();
　
/* NOTREACHED */
}
　
一种常见的错误是误将绝对的时间值传递给schedule_timer。例如，考虑一个不同的例子：
　
ACE_Time_Value delay = ACE_OS::atoi (argv[1]);
delay += ACE_OS::gettimeofday ();
　
// Callback every following 10 seconds.
ACE_Time_Value interval = delay + 10;
　
ACE_Reactor::instance ()->schedule_timer
(&handler,
0,
delay,
interval);
　
但是，该定时器在将来很长的时间内都不会到期，因为它将本日的当前时间加到了用户所要求的delay和interval上。
下面是实现具体事件处理器时，为最小化与绝对的ACE_Time_Value有关的问题，所应遵从的设计准则：
　
设计准则5：不要将绝对时间用作ACE_Reactor::schedule_timer的第三或第四参数。一般而言，这些参数应该小于一个极长的延迟，更远小于当前时间。
　
7.5.4 小心追踪ACE_Event_Handler的生存期
　
对登记到ACE_Reactor上的ACE_Event_Handler的跟踪失败会导致各种问题。不使用像Purify[24]这样的内存错误检测工具，很难去追踪这些问题；但这样的工具也只能捕捉下面的一些、而不是全部的与生存期相关的问题：
　
7.5.4.1 保守地使用非动态分配的事件处理器
　
考虑下面的具体事件处理器的定义：
　
class My_Event_Handler : public ACE_Event_Handler
{
public:
My_Event_Handler (const char *str = "hello")
: str_ (ACE_OS::strnew (str)) {}
　
virtual int handle_close
(ACE_HANDLE = ACE_INVALID_HANDLE,
ACE_Reactor_Mask = ACE_Event_Handler::READ_MASK)
{
// Commit suicide.
delete this;
}
　
~My_Event_Handler (void)
{
delete [] this->str_;
}
　
// ...
　
private:
char *str_;
};
　
该类在从ACE_Reactor上移除时，通过它的handle_close清扫方法删除它自己。尽管这看起来有一点不太传统，它却是完全有效的C++习语。但是，它仅在正被删除的对象是动态分配的的情况下才能够工作。
相反，如果正被删除的对象不是动态分配的，全局动态内存堆将会被破坏。原因是delete操作符将把this解释为堆中有效的地址。当delete操作符试图将非堆的内存插入它的内部空闲表时，就会造成微妙的内存管理问题。
下面的例子演示一个常见的可导致堆崩溃的使用实例：
　
int main (void)
{
// Non-dynamically allocated.
My_Event_Handler my_event_handler;
　
ACE_Reactor::instance ()->register_handler
(&my_event_handler,
ACE_Event_Handler::READ_MASK);
　
// ...
// Run event-loop.
while (/* ...event loop not finished... */)
ACE_Reactor::instance ()->handle_events ();
　
// The <handle_close> method deletes an
// object that wasn’t allocated dynamically...
ACE_Reactor::instance ()->remove_handler
(&my_event_handler,
ACE_Event_Handler::READ_MASK);
　
return 0;
}
　
上 面代码的问题是remove_handler被调用时，ACE_Reactor将会调用My_Event_Handler的handle_close方 法。遗憾的是，handle_close方法会对my_event_handler对象执行delete this操作，而此对象并非是动态分配的。
防止发生此问题的一种方法是将析构器放置在My_Event_Handler的私有区域，也就是：
　
class My_Event_Handler : public ACE_Event_Handler
{
public:
My_Event_Handler (const char *str);
// ...
　
private:
// Place destructor into the private section
// to ensure dynamic allocation.
?My_Event_Handler (void);
// ...
};
　
在此类中，My_Event_Handler的析构器被放置在类的私有访问控制区中。这种C++习语确保该类的所有实例都必须是动态分配的。如果实例被偶然地定义为static或auto，它在编译时就会被作为错误标记出来。
下面是实现具体事件处理器时，为最小化与具体事件处理器的生存期相关的问题，所应遵从的设计准则：
　
设 计准则6：不要delete不是动态分配的事件处理器。任何含有delete this、而其类又没有私有析构器的handle_close方法，都有可能违反这一设计准则。在缺乏一种能够静态地识别这一情况的规约检查器时，应该在 delete this的紧前面加上注释，解释为何要使用这一习语。
　
7.5.4.2 适当地解除具体事件处理器的登记
　
下面的程序演示与具体事件处理器的生存期相关的另一种常见错误：
　
ACE_Reactor reactor;
　
int main (void)
{
My_Event_Handler my_event_handler;
　
ACE_Reactor::instance ()->register_handler
(&my_event_handler,
ACE_Event_Handler::READ_MASK);
　
while (/* ...event loop not finished... */)
ACE_Reactor::instance ()->handle_events ();
　
// The destructor of the ACE_Reactor singleton
// will be called when the process exits. It
// removes all registered event handlers.
return 0;
}
　
my_event_handler 的生存期由main函数的生存期决定。相反，ACE_Reactor单体的生存期由进程的生存期决定。因而，当进程退出时，反应堆的析构器将会被调用。通 过调用所有仍然登记在册的事件处理器的handle_close方法，ACE_Reactor的析构器将这些处理器全部移除掉。但是，如果 my_event_handler仍然登记在Reactor上，它的handle_close方法将会在该对象出了作用域、并被销毁之后调用。
下面是实现具体事件处理器时，为最小化与具体事件处理器的生存期相关的问题，所应遵从的其他三条设计准则：
　
设 计准则7：总是从堆中动态分配具体事件处理器。这是解决许多与具体处理器的生存期有关的问题的相对直接的方法。如果不可能遵从此准则，必须在具体事件处理 器登记到ACE_Reactor时给出注释，解释为什么不使用动态分配。该注释应该在将静态分配的具体处理器登记到ACE_Reactor的 register_handler语句的紧前面出现。
　
设计准则8：在ACE_Event_Handler退出它们“生活”的作用域之前，从与它们相关联的ACE_Reactor中将它们移除掉。该准则应在未遵从准则7的情况下使用。
　
设 计准则9：只允许在handle_close方法中使用delete this习语，也就是，不允许在其他handle_* 方法中使用delete this。该准则有助于检查是否有与删除非动态分配的内存有关的潜在错误。自然，与ACE_Reactor无关的组件可以拥有不同的对自删除进行管辖的准 则。
　
设计准则10：仅在为具体事件处理器所登记的最后一个事件已从ACE_Reactor中移除时执行delete this操作。过早删除在ACE_Reactor上登记了多个事件的具体处理器会导致“晃荡的指针”，遵从此准则可以避免发生这样的情况。
例如，my_event_handler可以登记READ和WRITE事件，如下所示：
　
ACE_Reactor::instance ()->register_handler
(&my_event_handler,
ACE_Event_Handler::READ_MASK
| ACE_Event_Handler::WRITE_MASK);
　
　 　在此情形下，当handle_input返回-1时，ACE_Reactor将调用handle_close清扫挂钩方法。在具体事件处理器登记的 WRITE_MASK也被移除之前（例如，让它返回一个负值，或是通过下面的语句显式地将它移除），该方法不能执行delete this操作。
　
ACE_Reactor::instance ()->remove_handler
(&my_event_handler,
ACE_Event_Handler::WRITE_MASK);
　
下面的方法演示追踪此信息的一种途径：
　
class My_Event_Handler : public ACE_Event_Handler
{
public:
My_Event_Handler (void)
{
// Keep track of which bits are enabled.
ACE_SET_BITS (this->mask_,
ACE_Event_Handler::READ_MASK
| ACE_Event_Handler::WRITE_MASK);
　
// Register ourselves with the Reactor for
// both READ and WRITE events.
ACE_Reactor::instance ()->register_handler
(this, this->mask_);
}
　
virtual int handle_close (ACE_HANDLE h, ACE_Reactor_Mask mask)
{
if (mask == ACE_Event_Handler::READ_MASK)
{
ACE_CLR_BITS (this->mask_,
ACE_Event_Handler::READ_MASK);
　
// Perform READ_MASK cleanup logic.
}
else if (mask == ACE_Event_Handler::WRITE_MASK)
{
ACE_CLR_BITS (this->mask_,
ACE_Event_Handler::WRITE_MASK);
　
// Perform WRITE_MASK cleanup logic.
}
　
// Only delete ourselves if we’ve been closed
// down for both READ and WRITE events.
if (this->mask_ == 0)
delete this;
}
　
// ... handle_input() and handle_output() methods.
　
private:
ACE_Reactor_Mask mask_;
// Keep track of when to delete this.
};
　
上面的解决方案维护ACE_Reactor_Mask，追踪何时一个具体事件处理器登记的所有事件已被从ACE_Reactor移除。
　
7.5.5 注意WRITE_MASK语义
　
　　下面的代码指示ACE_Reactor，只要可以无阻塞地向一个句柄写，就回调一个event_handler。
　
ACE_Reactor::instance ()->mask_ops
(event_handler,
ACE_Event_Handler::WRITE_MASK,
ACE_Reactor::ADD_MASK);
　
但 是，除非连接被流控制，否则总是可以向一个句柄写。因此，反应堆会持续地回调event_handler的handle_output方法，直到（1）发 生连接流控制或（2） mask_ops方法被指示清除WRITE_MASK。一种常见的编程错误是忘记清除此掩码，导致ACE_Reactor不断地调用 handle_output方法。应遵从下面的设计准则来避免这一问题：
　
设计准则11：当你不再需要具体事件处理器的handle_output方法被回调时，清除WRITE_MASK。
　　下面的代码演示怎样确保handle_output方法不再被回调：
　
ACE_Reactor::instance ()->mask_ops
(event_handler,
ACE_Event_Handler::WRITE_MASK,
ACE_Reactor::CLR_MASK);
　
ACE_Reactor还定义了完成同样操作的简捷方法：
　
ACE_Reactor::instance ()->cancel_wakeup
(event_handler,
ACE_Event_Handler::WRITE_MASK);
　
这些方法通常在已不再有在具体事件处理器上待决的输出消息时被调用。
　
为 帮助自动查验此准则，程序员必须在他们的handle_output方法中插入注释，这些注释指示哪些返回路径不会清除WRITE_MASK，也就是，事 件处理器想要在“可以写”时继续被回调。同样地，程序员还应该注释那些WRITE_MASK被清除的路径。如果在handle_output方法中没有路 径清除WRITE_MASK，那就意味着可能违反了此准则。
例如，下面的handle_output方法演示此设计准则的可能的应用：
　
int My_Event_Handler::handle_output (ACE_HANDLE)
{
if (/* output queue is now empty */)
{
ACE_Reactor::instance ()->cancel_wakeup
(event_handler,
ACE_Event_Handler::WRITE_MASK);
/* Removing WRITE_MASK */
return 0;
} else
{
// ... continue to transmit messages
// from the output queue.
/* Not removing WRITE_MASK */
return 0;
}
}
　
如果没有注释指示对WRITE_MASK的清除，就有可能违反了此设计准则。
　
7.5.6 适当地登记具体事件处理器
　
当为I/O操作在ACE_Reactor上登记具体事件处理器时，选择下面的方法中的一种：
　
显式地传递句柄：该方法使用下面的ACE_Reactor方法：
　
int register_handler
(ACE_HANDLE io_handle,
ACE_Event_Handler *event_handler,
ACE_Reactor_Mask mask);
　
并显式地传递I/O设备的ACE_HANDLE，也就是：
　
void register_socket (ACE_HANDLE socket,
ACE_Event_Handler *handler)
{
ACE_Reactor::instance ()->register_handler
(socket,
handler,
ACE_Event_Handler::READ_MASK);
// ...
}
　
注意此register_handler方法允许同一个具体事件处理器与多个ACE_HANDLE一起进行登记。反应堆的这一特性使得我们有可能最小化处理许多客户所需的状态的数量；这些客户同时与同一事件处理器相连接。
　
隐式地传递句柄：该方法使用ACE_Reactor的另一个register_handler方法：
　
int register_handler
(ACE_Event_Handler *event_handler,
ACE_Reactor_Mask mask);
　
在 这种情形下，ACE_Reactor执行一次“双重分派”（double-dispatch）[6]来通过具体事件处理器的get_handle方法从处 理器中获取底层的ACE_HANDLE。该方法在ACE_Event_Handler基类中定义，具有特征const：
　
virtual ACE_HANDLE get_handle (void) const;
　
当 使用隐式登记时，常见的一种错误是在从ACE_Event_Handler派生子类时忽略了get_handle上的const。这样的疏忽将导致编译器 不能适当地在子类中重定义get_handle方法。相反，它将在子类中隐藏该方法，从而产生代码、调用基类的get_handle方法；该方法缺省返回 -1。
因此，服从下面的设计准则十分重要：
　
设计准则12：确定get_handle方法的特征与 ACE_Event_Handler基类中的一致。如果你不遵从此准则，并且你“隐式地”将ACE_HANDLE传递给ACE_Reactor， ACE_Event_Handler基类中的缺省get_handle将返回-1，而这是错误的。
　
7.5.7 从反应堆中移除已关闭的句柄/处理器
　
当连接被关闭时，句柄就不再能用于I/O。在这样的情况下，select将会持续地报告句柄“读就绪”，这样你就可以在句柄上调用close了。此步骤通常在handle_close清扫方法中完成。
一个常见的错误是对已死句柄及其事件处理器的移除的失败。这样ACE_Reactor将会持续地回调事件处理器的handle_input方法，直到它被从ACE_Reactor中移除。下面的设计准则有助于避免这一问题：
　
设计准则13：当连接关闭时（或当连接上发生错误时），从handle_* 方法中返回一个负值。
　
遵从此设计准则的代码通常被构造如下：
　
int handle_input (ACE_HANDLE handle)
{
// ...
ssize_t result = ACE_OS::read (handle, buf, bufsize);
　
if (result <= 0)
// Connection has closed down or an
// error has occurred.
return -1;
else
// ...
　
当 返回-1时，ACE_Reactor将调用你的handle_close清扫方法。为避免资源泄漏，确定该方法给了事件处理器以机会来删除它自己，并关闭 它的句柄（例如，ACE_OS::close (handle)）。一旦handle_close返回，ACE_Reactor就有机会从它的内部表中移除句柄/处理器对。
　
7.5.8 使用DONT_CALL标志来避免递归的handle_close()回调
　
前 面的准则描述了在应用显式或隐式地（通过从handle_* 挂钩方法中返回负值）调用它的remove_handler时，ACE_Reactor怎样自动调用handle_close方法。但是，如果应用在 handle_close清扫方法中调用remove_handler，就必须特别小心，因为这有可能触发无限递归。下面的准则处理这一问题。
　
设计准则14：在handle_close方法中调用remove_handler时，总是传递给它DONT_CALL标志。该准则确保ACE_Reactor不会递归地调用handle_close方法。下面的代码演示怎样应用此准则：
　
int My_Event_Handler::handle_close
(ACE_HANDLE,
ACE_Reactor_Mask)
{
// ...
　
ACE_Reactor::instance ()->remove_handler
(this->get_handle (),
// Remove all the events for which we’re
// registered. We must pass the DONT_CALL
// flag here to avoid infinite recursion.
ACE_Event_Handler::RWE_MASK |
ACE_Event_Handler::DONT_CALL);
　
// ...
}
　
顺 便说一下，remove_handler通常在下列情况下在handle_close中被调用：（1）为多个事件登记了同一个具体事件处理器，以及（2） handle_close第一次被调用时需要触发事件处理器的完全关闭。因而，handle_close还应该移除在ACE_Reactor中与该事件处 理器相关联的其他事件。
　
7.6 结束语
　
ACE_Reactor是设计用于简化并发的、事件驱动的分布式应用的OO构 架。通过在OO C++接口中封装低级的OS事件多路分离机制，ACE_Reactor使得开发正确、简洁、可移植和高效的应用变得更为容易。同样地，通过分离策略与机 制，ACE_Reactor增强了复用、改善了可移植性，并提供了透明的可扩展性。
下面的C++语言特性对ACE_Reactor的设计和使用它的功能的应用有所帮助：
　
类：C++类提供的封装改善了可移植性。例如，ACE_Reactor类将应用与像WaitForMultipleObjects和select这样的OS事件多路分离器之间的差异屏蔽开来。
　
对象：将C++对象、而不是单独的函数登记到ACE_Reactor有助于将应用特有的状态和使用此状态的方法集成在一起。
　
继承和动态绑定：通过允许开发者不修改现有代码就增强ACE_Reactor及与其相关联的应用的功能，这些特性促进了透明的可扩展性。
　
模 板：通过将可变性引入统一的类（它们可被“插入“到通用模板中），C++参数化类型有助于增强可复用性。例如，除了Logging_Handler和 ACE_SOCK_Acceptor，ACE_Acceptor还可用SVC_HANDLER和PEER_ACCEPTOR实例化。
　
使 用ACE_Reactor的一个潜在的不利方面是一开始很难理解应用的主线程控制在哪里执行。这是与事件循环回调分派器（比如ACE_Reactor或X -windows）相关的一个常见问题。但是，在使用此方法编写若干应用后，围绕这种“间接事件回调”分派模型的迷惑通常就会消失了。
ACE_Reactor和ACE socket包装的C++源代码和文档可在http://www.cs.wustl.edu/~schmidt/ACE.html找到。这一版本还包括一套测试程序和例子，以及许多其他封装命名管道、流管道、mmap和系统V IPC机制（也就是，消息队列、共享内存和信号量）的C++包装。
　
感谢