ACE
的陷阱
坦白說，使用這個標(biāo)題無非是希望能夠吸引你的眼球,這篇文章的目的僅僅是為了揭示一些ACE缺陷的。文章適合的讀者是對ACE（ADAPTIVE Communication Environment）有一定研究，或者正在使用ACE從事項目開發(fā)的人士參考。如果你對C++還是新手，甚至包括ACE知識初學(xué)者，（但你想飛的更高），建議你收藏這篇文檔以后閱讀。
秉承陷阱系列文章的傳統(tǒng)，我只是通過一些辯證的角度去看ACE的一些不足，對于ACE的強大和優(yōu)美我就不再作贊美。從2000年，到現(xiàn)在，ACE在中國已經(jīng)從星星之火，開始有燎原之勢。這一方面說明ACE的優(yōu)美和實力已經(jīng)逐步得到大家的認(rèn)可（我所知道的Adobe reader的使用ACE，估計是為了跨平臺，國內(nèi)的大量電信的網(wǎng)管，計費，智能網(wǎng)軟件也使用ACE），一方面要感謝的是的馬維達這位國內(nèi)少有的職業(yè)作家，國內(nèi)的ACE的中文資料（包括大量免費資料）都出自這位老兄。
但ACE無疑是復(fù)雜的，能夠暢快的遨游在其中的絕對不是泛泛之輩。沒有對網(wǎng)絡(luò)，設(shè)計模式，操作系統(tǒng)有一定的底蘊，想痛快的駕馭ACE無疑是較難的。另外，由于ACE仍然處在逐步發(fā)展的過程中。他的很多問題仍然有待進一步完善。重要的是一些文案的不足，受眾面狹小，導(dǎo)致許多ACE的使用者在使用ACE的時候會碰上很多問題。這篇文案就是用于徹底揭示部分這些問題。希望大家能在更加順捷的使用它。
另外，請注意我使用的陷阱這個術(shù)語，而不是原罪。（C Trap and Pitfalls 倒有很多應(yīng)該是Original sin）ACE還在不停的發(fā)展中。很多問題可能會在以后的版本中間改進。所以在我認(rèn)為的的確是問題的章節(jié)后面，我會附上知道錯誤的版本號。
作為一個代碼級的中間件。ACE無疑是高效的，但是坦白說ACE的代碼不是非常完美的。ACE的很多地方提供的是一個框架解決方案，為了保證框架的可移植和通用，代碼中大量使用了virtual 函數(shù)，Bridge模式，多線程下的鎖操作，甚至有相當(dāng)?shù)?/span>new操作……，這些東西都限制ACE的性能。所以個人謹(jǐn)慎的將ACE的效率定義為中上。
個人認(rèn)為，一般情況下，如果你使用ACE的API代替系統(tǒng)API，速度應(yīng)該降低0.01%以下，主要導(dǎo)致這些差役在于ACE的再次封裝，而函數(shù)棧的調(diào)用成本應(yīng)該可以幾乎不計。ACE的優(yōu)勢在高性能的系統(tǒng)架構(gòu)，而不是絕對的函數(shù)性能，如果你要再考慮在加入系統(tǒng)框架的其它功能呢，（舉一個例子，當(dāng)你想把定時器優(yōu)美的合入你的代碼時），ACE就有足夠的優(yōu)勢讓你選擇他。【注】
在此啰嗦一句，同樣也有很多人質(zhì)疑STL的性能。所有好的類庫一樣，他帶來優(yōu)勢的同時也會有一定的遺憾，比如少量性能降低。但是如果說他們的性能不好，那是無稽之談。（不信，把你認(rèn)為性能差的代碼給我寫寫看。）建議固步自封的程序員不要再干買櫝還珠的事情，先去讀讀那些優(yōu)美的代碼。
但是和所有的框架一樣，ACE也有不少的地方的地方是性能的暗礁，你最好繞開。當(dāng)然一般而言ACE會提供多條道路，重要的是你能選擇正確。
ACE的有多個層次，側(cè)記缺陷這類錯誤往往出現(xiàn)在ACE的高階封裝中。同時由于ACE是一個跨平臺的中間件。所以為了平臺的兼容性，ACE做了很多折中和彌補，有些是很漂亮的，但有些卻不是非常理想。
所有的代碼都是不完美的，特別是ACE這種要讓無數(shù)人在無數(shù)環(huán)境下使用的軟件。很多使用不便的問題都是來自我個人的一些習(xí)慣，這些算是苛責(zé)了。
由于ACE的龐大性，很多時候大家會錯誤的理解使用ACE的某些代碼實現(xiàn)某些特性。在此將寫一些曾經(jīng)讓我們栽跟頭的陰溝寫出來。另一方面，ACE的文檔的某些介紹也存在含混，會誤導(dǎo)大家的理解，錯誤的地方。
很多人在Windows使用ACE的時候往往會出現(xiàn)以下的Link錯誤。
Why do I get errors while using 'TryEnterCriticalSection'?
\ace/OS.i(2384) : error C2039:
'TryEnterCriticalSection': is not a member of '`global namespace''
其實這個錯誤不是由于ACE導(dǎo)致的，只是編譯器把這個贓栽倒了ACE上。出現(xiàn)這個錯誤的原因主要是因為一些關(guān)鍵宏定義沖突，一般是_WIN32_WINNT，'TryEnterCriticalSection' 這個函數(shù)是NT4.0后才出現(xiàn)的函數(shù)，如果這個宏被定義的小于0x0400或者沒有定義，那么就會出現(xiàn)這個錯誤。
所以最簡單的處理方法是在自己的預(yù)定義頭文件中加入一行。
#if !defined (_WIN32_WINNT)
# define _WIN32_WINNT 0x0400
#endif
其實ACE自己對于宏的處理是比較嚴(yán)謹(jǐn)?shù)模?/span>ACE的config-win32-common.h中間就有這行定義，所以在一般而言，可以將ACE的頭文件包含定義放在在頂部，這樣也可以避免這個編譯錯誤。
預(yù)定義頭文件是一個良好的編程習(xí)慣，你可以將自己的大部分宏定義，include包含的本工程以外的外部.h文件。簡言之就是預(yù)定義頭文件中使用#include<>，表示包含工程以外文件，自己工程內(nèi)部只使用#include””，表示包含當(dāng)前工程目錄下的文件。大部分C/C++的程序員都有過鏈接和一些預(yù)定義沖突錯誤消耗大量的時間，原來我也是如此，但是在掌握預(yù)定義頭文件方法后，我?guī)缀鯖]有為這個問題折磨過。其實Virsual C++ 在生產(chǎn)MFC工程的時候，會自動幫你自動生產(chǎn)一個預(yù)定義頭文件stdafx.h，只是我們不善利用而已。
其實對于很多編譯器，使用預(yù)定義頭文件還可以加快編譯速度。Virusal C++的預(yù)定義會生產(chǎn)一個pch文件，基本可以提高編譯速度一倍。Virusal C++的工程中間有專門的預(yù)定義頭文件設(shè)置。C++ Builder采用可以采用的編譯宏（好像是專用的）加快編譯速度。大致的原理是編譯器會在對預(yù)定義頭文件中包含的文件進行與處理，在外部文件沒有發(fā)生改動的時候，編譯器可以使用編譯這些文件生成的中間文件加快編譯速度。
ACE有一個非常優(yōu)美的定時器隊列模型，他提供了4種定時器Queue讓大家使用：ACE_Timer_Heap，ACE_Timer_Wheel，ACE_High_Res_Timer，ACE_Timer_Hash。在《C++ Network Programming Volume 2 - Systematic Reuse with ACE and Frameworks》中間有相應(yīng)的說明，其中按照說明最誘人的的是：
ACE_Timer_Hash, which uses a hash table to manage the queue. Like the timing wheel implementation, the average-case time required to schedule, cancel, and expire timers is O(1) and its worst-case is O(n).
但是遺憾的是，ACE_Timer_Hash其實是性能最差的。幾乎不值得使用。我曾經(jīng)也被誘惑過，但是在測試中間發(fā)現(xiàn)，文檔中所述根本不屬實，在一個大規(guī)模定時器的程序中，我使用ACE_Timer_Hash發(fā)現(xiàn)性能非常不理想，檢查后發(fā)現(xiàn)ACE的源代碼如下：
template <class TYPE, class FUNCTOR, class ACE_LOCK, class BUCKET> int
ACE_Timer_Hash_T<TYPE, FUNCTOR, ACE_LOCK, BUCKET>::expire (const ACE_Time_Value &cur_time)
{
// table_size_為Hash的桶尺寸，如果要避免沖突，桶的數(shù)量應(yīng)該盡量大，
//每個桶可以理解為一個Hash開鏈的鏈表
// Go through the table and expire anything that can be expired
//遍歷所有的桶
for (size_t i = 0;
i < this->table_size_;
++i)
{
//在每個桶中檢查是否有要進行超時處理的元素
while (!this->table_[i]->is_empty ()
&& this->table_[i]->earliest_time () <= cur_time)
{
…………
簡單說明一下上面的代碼，ACE_Timer_Hash_T采用開鏈的Hash方式，每個桶就是一個鏈表，在超時檢查時所有的桶中是由有要進行超時處理的元素。所以在超時處理中ACE采用了遍歷所有元素的方法。但悖論是如果你希望Hash的沖突不大，你就必須將桶的個數(shù)調(diào)整的盡量多。我在測試中將上述的程序的Time_Queue替換為標(biāo)準(zhǔn)的的ACE_Timer_Heap，發(fā)現(xiàn)性能提高數(shù)百倍。
冷靜下來思考一下，這也是正常的。對于一個Hash的實現(xiàn)，保證查詢的速度，也就是通過定時器ID進行操作的速度是足夠快的。但是實際上對于定時器操作，最大的成本應(yīng)該是尋找要超時的定時器，對于Hash這種數(shù)據(jù)結(jié)構(gòu)，只能采用迭代遍歷的方式……， 所以采用Hash的低效是正常的。而原文應(yīng)該改為schedule, cancel,的最好時間復(fù)雜度是O(1)，最差是O(n),而expire的時間復(fù)雜度始終是O(n)。
這個問題至少倒5.6.1的版本還是存在的。我個人估計也不會得到解決。Hash的特性擺在那兒呢，除非ACE采用更加復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。
由于Reactor在各個平臺的默認(rèn)實現(xiàn)都取決于平臺的實現(xiàn)，比如在Windows下默認(rèn)的Reactor是WFMO_REACTOR，而在Linux和UNIX平臺，默認(rèn)的Reactor是Select_Reactor,而Reactor的實現(xiàn)往往取決于使用的反應(yīng)器底層實現(xiàn)，而這些反應(yīng)器的時間精度就決定了你的定時器的時間精度。下表大致反饋了一些常用的定時器的實現(xiàn)。
表1 常用Raactor的實現(xiàn)
|
Reactor
|
反應(yīng)器的底層實現(xiàn)
|
時間精度
|
|
ACE_Select_Reactor
|
select函數(shù)
|
使用struct timeval結(jié)構(gòu)進行超時處理; timeval 結(jié)構(gòu)可以精確倒微秒。
|
|
Dev_Poll_Reactor
|
poll或者而epoll
|
timeout參數(shù)的單位是毫秒。
|
|
ACE_WFMO_REACTOR
|
WaitForMultipleObjects
|
dwMilliseconds 的參數(shù)單位是毫秒
|
|
|
|
|
不過作為服務(wù)器的開發(fā)，我倒想不出什么地方需要精確到0.1s定時器的地方，了解一下差異性就足夠了。
WFMO_Reactor是ACE_Reactor在Windows下的默認(rèn)實現(xiàn)（為什么不選擇ACE_Select_Reactor作為默認(rèn)實現(xiàn)，可能是基于效率和強大性的考慮）,WFMO_Reactor的低層使用的函數(shù)是WaitForMultipleObjects和WSAEventSelect，WSAEnumNetworkEvents。其中WaitForMultipleObjects函數(shù)用于處理線程，互斥量，信號燈，事件，定時器等事件，而WSAEventSelect用于處理網(wǎng)絡(luò)IO事件。
由于Windows API和操作系統(tǒng)的特性不一樣，WFMO_Reactor在很多地方的表現(xiàn)和其他平臺不一致。 【注】
【注】其實這兩個問題在《C++ Network Programming Volume 2 - Systematic Reuse with ACE and Frameworks》中4.4 The ACE_WFMO_Reactor Class有說明。這兒算是借花獻佛。
由于WaitForMultipleObjects不是一個處理大量事件的函數(shù)，其最多處理64個事件句柄，而WFMO_Reactor自身為了處理使用了2個句柄，所以一個WFMO_Rector對象只能處理。
如果你想做大規(guī)模的網(wǎng)絡(luò)接入，62個事件句柄顯然是不夠的，特別是要同時處理IO事件時，導(dǎo)致這個不足的應(yīng)該是WFMO_Reactor的設(shè)計者的一個選擇。在賦予WFMO_Reactor強大的特性的同時，WFMO_Reactor的設(shè)計者只能讓網(wǎng)絡(luò)IO事件的數(shù)量委屈一下了。
WFMO_Reactor 選擇的是Windows的WSAEventSelect 函數(shù)作為網(wǎng)絡(luò)的IO的反應(yīng)器。但是WSAEventSelect函數(shù)的FD_WRITE的事件處理和傳統(tǒng)的IO反應(yīng)器（select）不同。下面是MSDN的描述。
The FD_WRITE network event is handled slightly differently. An FD_WRITE network event is recorded when a socket is first connected with connect/WSAConnect or accepted with accept/WSAAccept, and then after a send fails with WSAEWOULDBLOCK and buffer space becomes available. Therefore, an application can assume that sends are possible starting from the first FD_WRITE network event setting and lasting until a send returns WSAEWOULDBLOCK. After such a failure, the application will find out that sends are again possible when an FD_WRITE network event is recorded and the associated event object is set.
簡單翻譯就是，只有在三種條件下，WSAEventSelect才會發(fā)出FD_WRITE通知，一是使用connect或WSAConnect，一個套接字成功建立連接后；二是使用accept或WSAAccept，套接字被接受以后；三是若send、WSASend、sendto或WSASendTo函數(shù)返回失敗，而且錯誤是WSAEWOULDBLOCK錯誤后，緩沖區(qū)的空間再次變得可用時。【注】
【注】這種觸發(fā)方式在IO反應(yīng)器或者說IO多路復(fù)用模型中應(yīng)該被稱為邊緣觸發(fā)方式。select函數(shù)好像沒有這種觸發(fā)方式而是水平觸發(fā)方式， Epoll是支持這種方式的，但是默認(rèn)還是水平觸發(fā)，這種方式可能有更高的效率，但是代碼更加難寫。
可以這么理解，WSAEventSelect認(rèn)為套接字基本都是可寫狀態(tài)，它認(rèn)為你應(yīng)該大膽send。只有send出現(xiàn)WSAEWOULDBLOCK失敗后，你才需要使用WSAEventSelect反應(yīng)器。【注】
所以對于WFMO_Reactor的，你不可能依靠注冊（或者是喚醒）IO句柄進行寫操作，WMFO_Reactor很有可能不會去回調(diào)你的handle_output函數(shù)。
【注】對于網(wǎng)絡(luò)套接字，只要緩沖區(qū)還有空間就可以直接發(fā)送，除非緩沖區(qū)沒有空間了，才可能出現(xiàn)阻塞錯誤，所以直接send失敗的可能性很小，另外反復(fù)調(diào)用注冊IO句柄一類的操作其實是比較耗時的。其實先send，如果send失敗再注冊IO句柄到反應(yīng)器的方式應(yīng)該是一種更加高效的方式，高壓力的通訊服務(wù)器應(yīng)該選擇這個編寫方式。
我自己的通信服務(wù)器通過這個改造，提高的性能在15%左右（CPU占用率下降）。
由于WFMO_Reactor的這些特點，其實很大的限制了Reactor的可移植性。其實個人感覺如果你對系統(tǒng)特性沒有那么多要求，在Windows下選擇Select_Reactor替換WFMO_Reactor是更好的選擇。
6 盡量使用ID取消ACE_Event_Handler定時器
ACE的Reactor 提供了兩種方式取消定時器：
virtual int cancel_timer (ACE_Event_Handler *event_handler,
int dont_call_handle_close = 1);
virtual int cancel_timer (long timer_id,
const void **arg = 0,
int dont_call_handle_close = 1);
一種是使用定時器ID取消定時器，這個ID是定時器是的返回值，一種是采用相應(yīng)的ACE_Event_Handler指針取消定時器。一般情況下使用ACE_Event_Handler的指針取消定時器無疑是最簡單的方法，但是這個方法卻不是一個高效的實現(xiàn)。所以如果您的程序有大規(guī)模的定時器設(shè)置取消操作，建議盡量使用ID取消定時器。我們用ACE_Timer_Heap和ACE_Timer_Has兩個Timer_Queue剖析一下。
先選擇最常用的Time_Queue ACE_Timer_Heap舉例，其使用ACE_Event_Handler關(guān)閉定時器的代碼是：
template <class TYPE, class FUNCTOR, class ACE_LOCK> int
ACE_Timer_Heap_T<TYPE, FUNCTOR, ACE_LOCK>::cancel (const TYPE &type,
int dont_call)
{
// Try to locate the ACE_Timer_Node that matches the timer_id.
//循環(huán)比較所有的的ACE_Event_Handler的指針是否相同
for (size_t i = 0; i < this->cur_size_; )
{
if (this->heap_[i]->get_type () == type)
{
………………
}
}
而使用TIMER_ID關(guān)閉的代碼如下，它是通過數(shù)組下標(biāo)進行的定位操作。
template <class TYPE, class FUNCTOR, class ACE_LOCK> int
ACE_Timer_Heap_T<TYPE, FUNCTOR, ACE_LOCK>::cancel (long timer_id,
const void **act,
int dont_call)
{
//通過數(shù)組下標(biāo)操作，速度當(dāng)然奇快無比。
ssize_t timer_node_slot = this->timer_ids_[timer_id];
……
//跟進數(shù)組ID進行操作
else
{
ACE_Timer_Node_T<TYPE> *temp =
this->remove (timer_node_slot);
}
}
對于ACE_Timer_Heap，采用ACE_Event_Handler指針取消定時器的方式的平均時間復(fù)雜度應(yīng)該就是O(N)。由于ACE的的一個Event_handler可能對應(yīng)多個定時器，所以必須檢查所有的才能確保取消所有的相關(guān)定時器。
對于Timer_Hash，其通過ACE_Event_Handler關(guān)閉定時器的代碼是：
template <class TYPE, class FUNCTOR, class ACE_LOCK, class BUCKET> int
ACE_Timer_Hash_T<TYPE, FUNCTOR, ACE_LOCK, BUCKET>::cancel (const TYPE &type,
int dont_call)
{
Hash_Token<TYPE> **timer_ids = 0;
//根據(jù)Event Handler有一個定時器new一個數(shù)組出來
ACE_NEW_RETURN (timer_ids,
Hash_Token<TYPE> *[this->size_],
-1);
size_t pos = 0;
//根據(jù)定時器的個數(shù)再進行取消
for (i = 0;
i < this->table_size_;
++i)
{
ACE_Timer_Queue_Iterator_T<TYPE,
ACE_Timer_Hash_Upcall<TYPE, FUNCTOR, ACE_LOCK>,
ACE_Null_Mutex> &iter =
this->table_[i]->iter ();
可以看到Timer_Hash的cancel比ACE_Timer_Heap的cancel（Event_Handler）要好一點點。但是其中也有new和delete操作，這些操作也不是高效操作。
所以說在大規(guī)模的定時器使用中，推薦你還是使用定時器的ID取消定時器更加高效的多。
ACE_Pipe是一個跨平臺的管道實現(xiàn)。標(biāo)準(zhǔn)情況來講，采用的實現(xiàn)，但是在最大的兩個平臺Windows和Linux上，ACE的實現(xiàn)是采用的Socket實現(xiàn)。
int
ACE_Pipe::open (int buffer_size)
{
ACE_TRACE ("ACE_Pipe::open");
#if defined (ACE_LACKS_SOCKETPAIR) || defined (__Lynx__)
//綁定了一個本地端口，0.0.0.0，然后找到相應(yīng)的端口，用于后面的鏈接
if (acceptor.open (local_any) == -1
|| acceptor.get_local_addr (my_addr) == -1)
result = -1;
else
{
// Establish a connection within the same process.
if (connector.connect (writer, sv_addr) == -1)
result = -1;
……
所以很多管道特性所特有的東西，在這兩個平臺上是無法使用ACE_Pipe實現(xiàn)的。比如，管道的特性可以保證在暫時沒有接受者的情況下使用，而Socket是不可能有這個特性的。你必須保證先有接受者，后有發(fā)送者的時序。
所以在這些平臺上最好不用這個封裝。
在Reactor的模式，有一種輔助的通知機制,Notify機制，簡單說就是通過通知發(fā)起者調(diào)用notify函數(shù)，notify的消息被保存在一個管道中，handle_event的處理中會檢查這個管道中是否有通知數(shù)據(jù)，如果有就根據(jù)通知的消息，會根據(jù)默認(rèn)的通知消息的類型去調(diào)用hanle_input等函數(shù)。
從設(shè)計的角度將，這個機制無疑是非常優(yōu)美的，對于Reactor，它在IO驅(qū)動以外，提供了一種新的驅(qū)動方式。但是從實現(xiàn)角度來講，這個機制要慎用。原因有兩個。
ACE Reactor的默認(rèn)Notify方式采用的是ACE_Pipe，所以ACE_Pipe在Windows和Linux平臺上的問題，Notify機制把ACE_Pipe的缺陷一個不少的繼承了，而且問題更加多。
/**
* Contains the ACE_HANDLE the ACE_Dev_Poll_Reactor is listening
* on, as well as the ACE_HANDLE that threads wanting the attention
* of the ACE_Dev_Poll_Reactor will write to.
*/
ACE_Pipe notification_pipe_;
原來在調(diào)試ACE代碼的時候，我發(fā)現(xiàn)只要一使用Reactor，即使只使用定時器（除非明確不使用Notify），防火墻都會報警有監(jiān)聽端口。我曾經(jīng)對此大惑不解，直到讀了ACE的這部分原代碼。這樣做的壞處有很多。第一個是由于采用的阻塞IO。速度會慢很多，第二個由于是單線程的處理，如果在壓力極大的情況下，可能出現(xiàn)死鎖的問題。比如在有大規(guī)模的Notify的情況下，發(fā)送緩沖區(qū)很可能會被塞滿（由于是單線程，這時不會有接受者），同時由于為了簡化，ACE_Pipe采用的IO是阻塞的，所以會導(dǎo)致整個程序死鎖。第三就是這樣的情況下ACE_Pipe會打開一個臨時的端口，而且會綁定所有的IP（0.0.0.0），如果對于一個安全要求嚴(yán)格的的場景，這個將是一個不可饒恕的錯誤。【注】
【注】在一個安全要求嚴(yán)格的環(huán)境下，這個臨時端口輕則可以讓你的服務(wù)器輕易陷于崩潰，重則可以讓你整個網(wǎng)絡(luò)被黑客攻陷。
不過還好的是ACE的開發(fā)者估計自己也意識倒了這個麻煩。所以提供了另外一種消息隊列的方式。你可以通過定義ACE_HAS_REACTOR_NOTIFICATION_QUEUE的宏編譯ACE，這樣ACE將不使用ACE_Pipe作為Notify消息的管道，而使用一個自己的內(nèi)存隊列保存Notify消息，這個隊列是動態(tài)擴展的。而且由于是內(nèi)存操作，性能方面沒有太大問題。
大體位置在重復(fù)編譯的衛(wèi)哨后面，#include /**/ "ace/pre.h"前面。保證這個宏起到作用。
#ifndef ACE_CONFIG_LINUX_H
#define ACE_CONFIG_LINUX_H
//使用內(nèi)存隊列作為Notify Queue
#define ACE_HAS_REACTOR_NOTIFICATION_QUEUE
#include /**/ "ace/pre.h"
這個問題到5.6.1還是存在的，估計由于歷史的原因，在很長一段時間也不會得到解決。
同上，這也應(yīng)該是一個BUG，Reactor Notify的代碼有考慮不周的地方。Notify機制的本質(zhì)是提供了一條消息隊列讓大家有方法調(diào)用Event_handler，但是存在一種可能，在你的通知消息在消息隊列的時候，Event_hanlder由于后面的處理可能已經(jīng)handle_close了。但是ACE的dispatch_notify卻沒有考慮倒這一點（或者說考慮倒這一點也不好解決）。
ACE_Select_Reactor_Notify::dispatch_notify函數(shù)的代碼。
int
ACE_Select_Reactor_Notify::dispatch_notify (ACE_Notification_Buffer &buffer)
{
…………
ACE_Event_Handler *event_handler =
buffer.eh_;
bool const requires_reference_counting =
event_handler->reference_counting_policy ().value () ==
ACE_Event_Handler::Reference_Counting_Policy::ENABLED;
//如果此時這個ACE_Event_Handler已經(jīng)被handle_close了，你如何是好。。。。
switch (buffer.mask_)
{
case ACE_Event_Handler::READ_MASK:
case ACE_Event_Handler::ACCEPT_MASK:
result = event_handler->handle_input (ACE_INVALID_HANDLE);
這個bug到5.6.1還沒有解決。我覺得這個問題是可以解決的（暫時還沒有提BUG），但是得到解決的方式卻仍然是低效的方案（還記得取消定時器的那個缺陷嗎）。
如果你仔細(xì)看過上面的幾節(jié)，你也許會發(fā)出驚嘆，啊，又是Reactor Notify？對，又是它。看起來我好像一直在和ACE的Notify機制在做對，但它的確讓我吃了無數(shù)的苦頭。這部分的設(shè)計的確有一點畫蛇添足的感覺，而且由于跨平臺性等原因，這個東東的實現(xiàn)一直不如意。其實自己使用ACE的實現(xiàn)（比如Message_Queue）一套這樣的機制應(yīng)該是易如反掌的事情。不苛求了。
如果你用不到Notify機制，最好在ACE_Reactor初始化的時候徹底關(guān)閉Notify機制。很多Reactor的初始化函數(shù)都提供了關(guān)閉notify pipe的方式。比如ACE_Select_Reactor_T的open函數(shù)的disable_notify_pipe參數(shù)。當(dāng)其為1的時候表示關(guān)閉notify 管道。
//disable_notify_pipe參數(shù)為1時表示關(guān)閉NOTIFY PIPE，不使用他
template <class ACE_SELECT_REACTOR_TOKEN> int
ACE_Select_Reactor_T<ACE_SELECT_REACTOR_TOKEN>::open
(size_t size,
int restart,
ACE_Sig_Handler *sh,
ACE_Timer_Queue *tq,
int disable_notify_pipe, /* 等于==1表示關(guān)閉notify機制 */
ACE_Reactor_Notify *notify)
不使用POLL和EPOLL【注】的人，估計不太知道這個ACE_Dev_Poll_Reactor，但實際上。特別是Linux下的EPOLL（一個IO多路服用模型），這是Linux大規(guī)模接入的重要法寶，從目前的表現(xiàn)來看，其他平臺上還沒有可以超越EPOLL的東西，Windows下的異步IO的性能也還遠(yuǎn)遠(yuǎn)遜于EPOLL。
如果要使用EPOLL而不是POLL，要使用宏ACE_HAS_EVENT_POLL編譯ACE，大體位置在重復(fù)編譯的衛(wèi)哨后面，#include /**/ "ace/pre.h"前面。保證起到作用。
#ifndef ACE_CONFIG_LINUX_H
#define ACE_CONFIG_LINUX_H
// ACE_HAS_EVENT_POLL宏用于定義使用EPOLL模塊，同時注意不同LINUX平臺下編譯可能有少量
//不同。我曾經(jīng)使用過的一個內(nèi)核2.4的Slackware平臺，要在編譯ACE的時候加入 –lepoll，可能是由于
//其是打補丁增加的功能
#define ACE_HAS_EVENT_POLL
#include /**/ "ace/pre.h"
但也許是由于這個東西過新還是由于設(shè)計者是一個定于時間要求很敏感的人。的設(shè)計明顯的是定時器優(yōu)先。但是了解EPOLL和POLL的人都知道，UNIX和Linux設(shè)計這兩個咚咚的目的就是解決大規(guī)模IO復(fù)用。不是為了保證定時器優(yōu)先，所以我對這個設(shè)計很是不解，郁悶。其大體思路為，
1.) 先檢查定時器超時的隊列，計算最小的超時時間，用于IO等待。
2.) 觸發(fā)IO事件
3.) 處理超時的Handler，如果有超時的事件，返回（1）。這點我看得最郁悶。
4.) 再分發(fā)處理IO事件
可以看到在處理超時句柄的時候，ACE_Dev_Poll_Reactor發(fā)現(xiàn)有超時的事件會返回到檢查超時隊列。所以如果在Reactor同時有定時處理，IO的優(yōu)先級會很低。
其實這個的設(shè)計者也知道這個問題。他在代碼中間做了如下的記錄。
int
ACE_Dev_Poll_Reactor::dispatch (Token_Guard &guard)
{
……
// Handle timers early since they may have higher latency
// constraints than I/O handlers. Ideally, the order of
// dispatching should be a strategy...
if ((result = this->dispatch_timer_handler (guard)) != 0)
return result;
由于EPOLL的特性，使用它大部分都是為了處理大規(guī)模的IO請求，定時器其實只有少量的需求，不是我們需求的重點。
這個問題到最近的5.6.1版本沒有得到解決。
我曾經(jīng)反饋過這個問題。但是得到?jīng)]有明確的解答。解決這個問題的方法其實也很簡單，自己重載這個類，然后自己實現(xiàn)相應(yīng)的函數(shù)。觸發(fā)IO事件后立即分發(fā)IO事件，而且加入了一個IO的優(yōu)先級別。在多次IO處理的循環(huán)后在進入時間事件處理。保證時間處理的粒度在1s以內(nèi)基本就可以了。
在程序退出的【注】，我們往往不會自己關(guān)閉Event_Handler，而寄希望Reactor 的清理。但是實際情況會復(fù)雜很多。使用的時候必須當(dāng)心。
【注】是否要在退出的時候清理所有分配的內(nèi)存？在普通的操作系統(tǒng)中，程序的退出會回收所有的分配內(nèi)存。所以很多人會逃避在最后階段的清理分配的內(nèi)存。但是這實在不是一個良好的喜歡。一方面對于很多OS（比如嵌入系統(tǒng)）不會回收內(nèi)存資源，一些內(nèi)核資源（UNIX）也不會在進程退出后釋放，編程就應(yīng)該要養(yǎng)成清理的好習(xí)慣，更何況不進行釋放在內(nèi)存檢查的軟件一般會報錯，如果不清理會干擾我們對于內(nèi)存泄露的定位。
10.1 Reactor的close可能不會關(guān)閉Event_Handler
理論上講，ACE_Reactor提供了一個close函數(shù)，所有的Event_Handler應(yīng)該統(tǒng)一在這個函數(shù)進行關(guān)閉。
ACE_Reactor采用的是模式，封裝了不同Reactor的實現(xiàn)。這些實現(xiàn)的close函數(shù)未存在一定的差異性。就我的閱讀和嘗試來看，Select_Reactor在close函數(shù)關(guān)閉了所有的IO句柄相關(guān)的Event_Handler，而Dev_Poll_Reactor的close實現(xiàn)就沒有關(guān)閉。
Select_Reactor的close代碼。
template <class ACE_SELECT_REACTOR_TOKEN> int
ACE_Select_Reactor_T<ACE_SELECT_REACTOR_TOKEN>::close (void)
{
……
//在handler_rep的close函數(shù)會關(guān)閉所有的register的句柄的handler，調(diào)用他們的
//handle_close函數(shù)
this->handler_rep_.close ();
Dev_Poll_Reactor的close的調(diào)用了函數(shù)ACE_Dev_Poll_Reactor_Handler_Repository::close，而后有逐步調(diào)用了unbind_all，remove_reference。
//close會經(jīng)過多級調(diào)用到ACE_Dev_Poll_Reactor_Handler_Repository:: unbind_all
//unbind被unbind_all函數(shù)調(diào)用decr_refcnt == true
int
ACE_Dev_Poll_Reactor_Handler_Repository::unbind (ACE_HANDLE handle,
bool decr_refcnt)
{……
// remove_reference函數(shù)沒有調(diào)用handle_close，而是減去了引用計數(shù)
if (decr_refcnt)
this->handlers_[handle].event_handler->remove_reference ();
……
}
ACE_Event_Handler::Reference_Count
ACE_Event_Handler::remove_reference (void)
{
//如果打開了引用計數(shù)，則使用應(yīng)用計數(shù)方式管理方式。但是代碼默認(rèn)不采用應(yīng)用計數(shù)模式
//所以下面的代碼都無法執(zhí)行
if (reference_counting_required)
{
//減去引用計數(shù)
Reference_Count result =
--this->reference_count_;
//如果已經(jīng)沒用引用個數(shù)了，刪除自己。
if (result == 0)
delete this;
}
可以看到ACE_Event_Handler的代碼默認(rèn)不采用應(yīng)用計數(shù)模式，（eference_counting_required默認(rèn)為DISABLED）而Dev_Poll_Reactor卻非要使用引用計數(shù)模式去清理Event_Handler。
我對Dev_Poll_Reactor為什么要設(shè)計成這樣表示不解。也對Dev_Poll_Reactor提交過BUG，但是Dev_Poll_Reactor的開發(fā)者不認(rèn)為這樣有什么不妥，本人E文羞澀，無法說服具體的開發(fā)人員，不過在提交BUG時，居然得到了Douglas反饋（他開始時認(rèn)同我的看法），對于他們的執(zhí)著和認(rèn)真還是表示敬仰。
這個問題是在工作中調(diào)試一個BUG出現(xiàn)的。
在測試一個服務(wù)器的時候發(fā)現(xiàn)Coredump發(fā)生kill進程，讓其退出在之后，會出現(xiàn)Coredump文件。Coredump顯示出現(xiàn)問題的地方在。
#1 0x0805bc7b in ~ACE_Timer_Heap_T (this=0x82d3ec8) at /usr/local/ACE_wrappers/ace/Timer_Queue_T.cpp:442
#2 0x0805b86d in ~ACE_Singleton (this=0x82cca70) at egg_application.cpp:52
#3 0x08056785 in ACE_Singleton<EggSvrdAppliction, ACE_Null_Mutex>::cleanup (this=0x82dfb90)
由于希望改變ACE_Time_Queue的特性（數(shù)量），我替換Reactor的默認(rèn)Time_Queue，所以必須自己銷毀自己管理的TimeQueue。而在外部最后銷毀的時候出現(xiàn)Coredump。由于和Time_Queue相關(guān)，我檢查了所有的Timer相關(guān)的Event_handler，發(fā)現(xiàn)有一個Event_handler沒有自己主動調(diào)用handler_close釋放，這個Event_handler只有定時器，沒有注冊任何IO事件。修改代碼為主動釋放后，再次測試就發(fā)現(xiàn)Coredump的問題得到解決。
我檢查了一下原有代碼堆棧的調(diào)用順序，找到了問題原因。
(1)ACE_Reactor::close，實際調(diào)用ACE_Select_Reactor::close
(2) Select_Reactor::close 嘗試關(guān)閉所有的IO句柄相關(guān)的Event_handler，但由于Time_Queue是外部傳入的參數(shù)，所以不清理Time_Queue。
(3)Time_Queue清理，Time_Queue的析構(gòu)函數(shù)被調(diào)用，Time_Queue的析構(gòu)函數(shù)會釋放所有的定時器相關(guān)的Event_handler。而他的釋放還會調(diào)用hanlder_close。但是這是Reactor對象已經(jīng)銷毀了。所以造成了Coredump。
注意由于Reactor的封裝了Event_handler定時器，IO句柄，Notify機制等回調(diào)接口。所以Event_handler可能只關(guān)聯(lián)到IO句柄，也可能只關(guān)聯(lián)定時器，同時Reactor的模型決定了他的內(nèi)部管理是復(fù)雜的。而在釋放的過程中很可能會發(fā)生交錯的問題，而，像上面問題的Event_handler就只關(guān)聯(lián)的定時器，所以在Reactor的close的時候沒有關(guān)閉。從而導(dǎo)致在后面的清理工作中產(chǎn)生時序問題。
最簡單的方式還是自己在程序退出前清理釋放所有的Event_handler.再調(diào)用Reactor的close。
由于我們采用的服務(wù)器一般都是靠紐扣電池作為能源驅(qū)動和記錄時鐘，一般在運行一段時間后都會出現(xiàn)時間誤差。所以很多大規(guī)模的分布系統(tǒng)都有校時操作，特別是一些對時鐘要求精確的分布式系統(tǒng)（比如計費等），往往都會有一個主機提供精確時鐘服務(wù)（其可能采用GPS校時），其他服務(wù)器通過這臺服務(wù)器校時，校時操作一般都是直接改變系統(tǒng)時鐘。
ACE的定時器都是采用Event_Handler進行處理，而Event_Handler一般而言都是采用絕對時間作為記錄超時的時間戳，但是絕對時間的方式在系統(tǒng)時鐘被調(diào)整的時候，會導(dǎo)致“丟失”部分定時器的處理，導(dǎo)致一些問題。
在設(shè)置定時器時，schedule_timer函數(shù)通過gettimeofday得到定時器時間點的時間。
template <class ACE_SELECT_REACTOR_TOKEN> long
ACE_Select_Reactor_T<ACE_SELECT_REACTOR_TOKEN>::schedule_timer
(ACE_Event_Handler *handler,
const void *arg,
const ACE_Time_Value &delay_time,
const ACE_Time_Value &interval)
{
// schedule_timer記錄的是系統(tǒng)時間,
if (0 != this->timer_queue_)
return this->timer_queue_->schedule
(handler,
arg,
timer_queue_->gettimeofday () + delay_time,
interval);
}
在派發(fā)定時器的過程中也是調(diào)用gettimeofday函數(shù)。
template <class TYPE, class FUNCTOR, class ACE_LOCK> ACE_INLINE int
ACE_Timer_Queue_T<TYPE, FUNCTOR, ACE_LOCK>::expire (void)
{
if (!this->is_empty ())
return this->expire (this->gettimeofday () + timer_skew_);
else
return 0;
}
可以看出，如果在schedule_timer后，將系統(tǒng)時鐘向前調(diào)節(jié)（調(diào)慢）以后，原有的定時器將要經(jīng)過更多的時間才能觸發(fā)。從而導(dǎo)致這段時間內(nèi)定時器無法觸發(fā)。從而造成定時器丟失。
這個問題的解決方法有2個，簡單方法是將系統(tǒng)時鐘校準(zhǔn)的頻度提高，保證每次校準(zhǔn)的時候，系統(tǒng)的時鐘出現(xiàn)的偏差都不會影響時鐘的定時器觸發(fā)。
另外一種是ACE的Timer_Queue自己提供的方法，通過上面的代碼我們可以發(fā)現(xiàn)，其實ACE_Timer_Queue_T::gettimeofday是一個調(diào)用的是一個函數(shù)指針。默認(rèn)使用ACE_OS:: gettimeofday函數(shù)，這個函數(shù)可以替換的。
void gettimeofday (ACE_Time_Value (*gettimeofday)(void));
ACE提供一個依賴于操作系統(tǒng)的高解析定時器，ACE_High_Res_Timer，這個類是通過OS的TICK數(shù)量來得到更加精確的時鐘的【注】。
【注】OS在啟動后，都會有一個TICK在不斷的計數(shù)，這個TICK就像一個打點計數(shù)器，每次增加1.一般計數(shù)周期就是一個CPU周期。
由于CPU的TICK不會隨著你調(diào)整系統(tǒng)時鐘而調(diào)整。所以可以看做是一個相對值。ACE_High_Res_Timer可以根據(jù)相對值計算得到非常精確的程序運行時鐘，。直接使用ACE_High_Res_Timer:: gettimeofday_hr函數(shù)作為ACE_Timer_Queue_T::gettimeofday函數(shù)指針。并且在程序的開始部分使用函數(shù)，ACE_High_Res_Timer::global_scale_factor ()，用于激活高精度定時器。【注】
【注】這個方法得益于原來公司的兩位同事zhangtianhu和liaobincai的一個終結(jié)。在此懷念一下和他們共事的日子。另外，我沒有仔細(xì)研究過這個方法，由于獲取CPU的TICK的獲取很有可能是一個內(nèi)核操作，效率可能不高。
采用上述的兩個方法基本可以避免這個問題。
12 ACE的CDR中的字節(jié)對齊問題
大家應(yīng)該都知道計算機中間都有字節(jié)對齊問題。CPU訪問內(nèi)存的時候，如果從特定的地址開始訪問一般可以加快速度，比如在32位機器上，如果一個32位的整數(shù)被放在能被32模除等于0的地址上，只需要訪問一次，而如果不在，可能要訪問兩次。但是這樣就要求一些數(shù)據(jù)從特定的地址開始，而不是順序排放（中間會有一些空余的地址），這就是字節(jié)對齊。
而ACE CDR的估計也是為了加快速度，從而在CDR編碼上默認(rèn)也使用了字節(jié)對齊。所以在ACE的CDR編解碼過程中，傳入的參數(shù)地址最好是能符合字節(jié)對齊規(guī)則，否則可能會編解碼錯誤。
ACE_OutputCDR構(gòu)造函數(shù)會調(diào)用一個函數(shù)mb_align調(diào)整傳入的地址參數(shù)成為地址對齊地址。但是其的調(diào)整函數(shù)ACE_ptr_align_binary不知處于什么考慮，不是按照機器的對齊長度而是采用的 ACE_CDR::MAX_ALIGNMENT（64bit，長度為8BYTPES）作為參數(shù)地址。那么ACE_OutputCDR的內(nèi)部地址是按照8字節(jié)作為對齊的，但是ACE_InputCDR卻沒有將內(nèi)部地址調(diào)整為模除64等于0的地址上，而只是調(diào)整為模除32（在32位機器上）等于0的地址。
void
ACE_CDR::mb_align (ACE_Message_Block *mb)
{
#if !defined (ACE_CDR_IGNORE_ALIGNMENT)
//如果使用字節(jié)對齊方式，使用最大的對齊方式調(diào)整內(nèi)存。調(diào)整為模除64等于0的地址上。
char * const start = ACE_ptr_align_binary (mb->base (),
ACE_CDR::MAX_ALIGNMENT);
#else
……
}
使用一段簡單的代碼可以測試發(fā)現(xiàn)這個問題。
char *tmp_buffer = new char [2048];
//使用一個無法對齊的參數(shù)作為ACE_InputCDR，ACE_OutputCDR的參數(shù)地址，
char *tmp_data = tmp_buffer +1;
// output_cdr調(diào)整了對齊的起始地址為8字節(jié)的默認(rèn)
ACE_OutputCDR output_cdr(tmp_data,512);
ACE_InputCDR input_cdr(tmp_data,512);
ACE_CDR::ULong cdr_long = 123;
bool bret =false;
//
bret = output_cdr.write_ulong(cdr_long);
// cdr_long 不等于123，而是一個錯誤無效數(shù)據(jù)。
bret = input_cdr.read_ulong(cdr_long);
其實如果編解碼的BUFF都采用相同的對齊方式，那么理論上也不應(yīng)該出現(xiàn)問題，最多是出現(xiàn)為了對齊而進行填補的空隙，但是這樣能帶來CPU的效率提升，也是好事。但是由于ACE_OutputCDR的一個地址調(diào)整。卻可能導(dǎo)致編解碼的BUFFER不一致，我不能肯定這到底是一個錯誤還是作者有他自己的考慮。
這個問題到5.6.1還存在。我已經(jīng)提交了問題報告。
當(dāng)然有一個方法解決這個問題。就是定義宏ACE_CDR_IGNORE_ALIGNMENT【注】，只要定義了這個宏，ACE就不會使用字節(jié)對齊處理CDR編碼。使用這個方法的，編碼占用空間會壓縮一些，但效率上可能低一點（其實未必，因為為了字節(jié)對齊還要耗費一些計算時間），
【注】ACE不知道為什么在代碼中使用兩個不使用字節(jié)對齊的宏，一個是在CDR_Base.h CDR_Base.cpp 文件中使用的是ACE_CDR_IGNORE_ALIGNMENT，在CDR_Stream.cpp和CDR_Stream.h文件上使用的宏ACE_LACKS_CDR_ALIGNMENT。
我一般將兩個宏都定義上。
這個純屬個人感覺（偏見）。我有如下理由不使用ACE的容器：
l 一些實現(xiàn)不符合大家對于容器的認(rèn)識，比如ACE_DLList，在其中存放的居然是對象的指針而不是拷貝。你還必須記住去釋放ACE_DLList內(nèi)部管理的指針。
l ACE容器的迭代器不符合STL的要求，從而造成ACE的容器無法使用STL的各種模板算法和函數(shù)。總不能因為ACE容器失去STL算法這片森林吧。
l 現(xiàn)在的編譯器上已經(jīng)非常普遍實現(xiàn)了STL，想找一個還不支持STL的編譯器應(yīng)該都不容易了。
l ACE的容器中間有大量指針，所以ACE的容器也不可能用在共享內(nèi)存中。其的應(yīng)用場景和STL沒有本質(zhì)區(qū)別。
ACE的文檔《The.ACE.Programmers.Guide》中間也說過：
That being said, the standard C++ containers are recommended for application development when you are using ACE.
所以在可以使用STL的情況下，還是優(yōu)先使用STL。
ACE的日志部分是一個非常漂亮的實現(xiàn),在多線程和多進程模型下都能較好的效率和安全使用。但是卻又少量的不足，讓人意猶未盡。
ACE日志對于時間戳的格式是固定的，采用的是格式，這個格式在西方人看起來估計還比較順眼，在東方人眼中卻不如人意。更好的方式當(dāng)然是時間戳的函數(shù)可以重載。或者用函數(shù)對象（指針）作為參數(shù)傳入。
雖然這部分代碼可以重載解決這個問題，但是要大動干戈只修正這個問題感覺卻又不值得的。
ACE提供了一個日志策略類ACE_Logging_Strategy輔助大家定義日志策略。但是他的初始化參數(shù)卻是命令行參數(shù)，而不是變量參數(shù)。
int
ACE_Logging_Strategy::init (int argc, ACE_TCHAR *argv[])
你必須使用這樣的命令行去初始化日志策略模塊。
-m1024 -N10 -fSTDERR|OSTREAM -s../log/c4ad.log
試問有幾個服務(wù)器的開發(fā)人員會將這些日志策略的初始化放到命令行參數(shù)上去。
ACE_Logging_Strategy的日志文件的分割策略采用的是按照文件大小分割文件，文件的序號采用滾動的，但這種日志分割方式無法根據(jù)文件時間了解日志內(nèi)容，（由于文件序號要滾動，序號文件的最后修改時間都一樣），你只能grep所有的日志尋找你要的內(nèi)容。
而在我看來，最好日志分割方式肯定是按照日期進行分割日志文件。每天創(chuàng)建一個新的日志文件，可以方便分割日志。清理和管理的工作量大大降低。
ACE_Logging_Strategy采用的是日志槽的方式Enable或者Disable某些級別的日志。但是感覺多少有點不自然的，ACE自己的日志級別本身就是分級的。個人感覺應(yīng)該是如果日志輸出的日志級別大于定義的級別就能輸出應(yīng)該是一個更好的選擇。
解決ACE_Logging_Strategy的問題最好的辦法還是擴展這個類。實現(xiàn)自己的日志策略類。
ACE_Time_Value是使用ACE會大量使用類。但是他的部分函數(shù)沒有高效的實現(xiàn)。比如構(gòu)造函數(shù)：
ACE_INLINE
ACE_Time_Value::ACE_Time_Value (time_t sec, suseconds_t usec)
和set函數(shù)
ACE_INLINE void
ACE_Time_Value::set (time_t sec, suseconds_t usec)
為了規(guī)范用戶的賦值，在這些函數(shù)的最后都會調(diào)用normalize函數(shù)。
void ACE_Time_Value::normalize (void)
但如果你的賦值的微秒數(shù)值不合適（過大）時，normalize卻不是一個高效實現(xiàn)。下面簡單摘取normalize的一段代碼。
void
ACE_Time_Value::normalize (void)
{
//如果賦值的大于微秒數(shù)值大于1s。
if (this->tv_.tv_usec >= ACE_ONE_SECOND_IN_USECS)
{
/*! \todo This loop needs some optimization. */
//作者都認(rèn)為這個代碼要優(yōu)化
//那么進入循環(huán)，每次減去1000000的微秒單位，在秒的單位+1，上帝呀。
do
{
++this->tv_.tv_sec;
this->tv_.tv_usec -= ACE_ONE_SECOND_IN_USECS;
}
while (this->tv_.tv_usec >= ACE_ONE_SECOND_IN_USECS);
}
…………
}
很不理解為什么會寫成如此的低效。為什么不直接使用除法呢，我很不理解。所以如果你在代碼的主循環(huán)中如果使用了ACE_Time_Value，使用上面的那些函數(shù)就可能掉入陷阱。
解決方法是盡量使用函數(shù)sec和usec賦值，這些函數(shù)不會調(diào)用normalize，這兩個函數(shù)會直接賦值。如果非要使用上面的那些函數(shù)方式，也一定不要使用過大的（錯誤的）時間參數(shù)。
這個問題到5.6.1還沒有得到修正。
ACE的非阻塞網(wǎng)絡(luò)函數(shù)參數(shù)設(shè)計有不合理的地方。ACE_SOCK_Stream和ACE_SOCK_Connector在非阻塞的的調(diào)用的接口對于ACE_Time_Value *timeout參數(shù)的使用不一致，一個要使用NULL，一個卻要使用ACE_Time_Value::zero。
ACE_SOCK_Stream，非阻塞調(diào)用send函數(shù)的時候【注】，timeout參數(shù)必須填寫為NULL。它最后調(diào)用的是ACE::send。將ACE_Time_Value填寫為ACE_Time_Value::zero （0,0）是不行的。如果填寫ACE_Time_Value::zero，會大大降低這個非阻塞調(diào)用的性能。
ssize_t
ACE::send (ACE_HANDLE handle,
const void *buf,
size_t n,
int flags,
const ACE_Time_Value *timeout)
{
if (timeout == 0)
return ACE_OS::send (handle, (const char *) buf, n, flags);
else
{
…………
}
}
timeout);
注意使用非阻塞的的IO要調(diào)用recv，send函數(shù)，而不要調(diào)用recv_n,send_n這些函數(shù)接口，這些函數(shù)接口如果timeout參數(shù)傳遞NULL，表示阻塞。
另外非阻塞IO還是要自己設(shè)置Socket的選項。
但是ACE_SOCK_Connector卻采用另外一個封裝方式，其是傳入一個NULL表示阻塞，而傳入ACE_Time_Value::zero （0,0）表示進行非阻塞鏈接操作。
* @param timeout Pointer to an @c ACE_Time_Value object with amount
* of time to wait to connect. If the pointer is 0
* then the call blocks until the connection attempt
* is complete, whether it succeeds or fails. If
* *timeout == {0, 0} then the connection is done
* using nonblocking mode. In this case, if the
* connection can't be made immediately, this method
* returns -1 and errno == EWOULDBLOCK.
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);
大家在處理這些IO時務(wù)必當(dāng)心。
這個”陷阱”的說法有點吹毛求疵，ACE提供了一種很前衛(wèi)的Makefile方式，他定義了Makefile的基礎(chǔ)變量，以及包括規(guī)則。如果使用他來輔助Makefile的書寫,特別是在跨平臺開發(fā)中，你可以大大節(jié)省Makefile開發(fā)時間。
BIN = hello_ace
BUILD = $(VBIN)
SRC = $(addsuffix .cpp,$(BIN))
LIBS = -lMyOtherLib
LDFLAGS = -L$(PROJ_ROOT)/lib
#---------------------------------------------------
#Include macros and targets
#---------------------------------------------------
include $(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
include $(ACE_ROOT)/include/makeinclude/macros.GNU
include $(ACE_ROOT)/include/makeinclude/rules.common.GNU
include $(ACE_ROOT)/include/makeinclude/rules.nonested.GNU
include $(ACE_ROOT)/include/makeinclude/rules.bin.GNU
include $(ACE_ROOT)/include/makeinclude/rules.local.GNU
但是麻煩就在于ACE的這些Makefile方法幾乎沒有一個文檔幫助說明，我一直無法理解$VBIN到底是什么。這也許，另外，定義到規(guī)則這一層也大大限制了大家對Makefile的擴展能力。這就有一點點高不成低不就的味道了，Makefile的新手幾乎不可能了解ACE的Makefile,老手又會因為特殊的需求得不到滿足而躊躇。而我個人一般只使用ACE定義的Makefile變量。這些變量大部分在wrapper_macros.GNU，platform_macros.GNU
表2 ACE Mafile的變量定義
|
變量
|
描述
|
|
AR
|
ar 命令的名字
|
|
ARFLAGS
|
ar 的參數(shù)
|
|
CC
|
C編譯器的命令的
|
|
CXX
|
C++編譯器的命令
|
|
RC
|
資源編譯器命令的名字
|
|
COMPILE.c
|
編譯C文件的命令行, 一般為:$(CC) $(CFLAGS) $(CPPFLAGS) -c
|
|
COMPILE.cc
|
編譯C++文件的命令行,一般為:$(CXX) $(CCFLAGS) $(CPPFLAGS) $(PTDIRS) –c
|
|
COMPILEESO.cc
|
$(CXX) $(CCFLAGS) $(CPPFLAGS) $(PTDIRS),沒太搞明白，不知道為什么和SO有關(guān)，好像是為了修正錯誤增加的。不理也罷
|
|
CPPFLAGS
|
C,C++語言編譯的預(yù)標(biāo)志，比如DEFINDE等. CPPFLAGS += $(DEFFLAGS) $(INCLDIRS)
|
|
CFLAGS
|
C語言編譯選項
|
|
CCFLAGS
|
C++語言編譯選項
|
|
DCFLAGS
|
Debugging 程序的C語言編譯選項,一般在有debug=1變量時有效
|
|
DCCFLAGS
|
Debugging 程序的C++語言編譯選項,一般在有debug=1變量時有效
|
|
DEFFLAGS
|
C++ 預(yù)處理的DEFINE部分
|
|
DLD
|
dynamic linker 動態(tài)庫link命令的名字，
|
|
LD
|
linker 命令的名字
|
|
IDL
|
CORBA IDL compiler 命令的名字
|
|
INCLDIRS
|
INCLUDE的頭文件
|
|
LDFLAGS
|
ld linker flags
|
|
LINK.c
|
鏈接C文件的命令行
|
|
LINK.cc
|
鏈接C++文件的命令行,一般為:$(PURELINK) $(PRELINK) $(LD) $(CCFLAGS) $(CPPFLAGS) $(PTDIRS)
|
|
MAKEFLAGS
|
Flags that are passed into the compilation from the commandline
|
|
OCFLAGS
|
Optimizing 程序的C語言編譯選項
|
|
OCCFLAGS
|
Optimizing 程序的C++語言編譯選項
|
|
PIC
|
PIC就是position independent code
|
|
PCFLAGS
|
profiling 程序的C語言編譯選項 profiling是什么不要問我。
|
|
PCCFLAGS
|
profiling 程序的C++語言編譯選項
|
|
PRELINK
|
LINK之前執(zhí)行的命令
|
|
PURELINK
|
purify 執(zhí)行的命令，purify是什么不要問我。
|
|
PWD
|
得到當(dāng)前目錄的命令
|
|
PTDIRS
|
模板文件的路徑定義
|
|
RM
|
刪除工具的命令
|
|
ACE_MKDIR
|
遞歸創(chuàng)建的目錄
|
|
SOFLAGS
|
生成.so庫時候的參數(shù)
|
|
SOLINK.cc
|
生成.so庫時候的命令行
|
|
VAR
|
Variant identifier suffix
|
|
VDIR
|
Directory for object code .obj/
|
|
VSHDIR
|
Directory for shared object code .shobj/
|
看起來變量很多，其實要記住和使用的可以很少，你需要留意的主要是.cc結(jié)尾的變量就可以了。我們可以使用ACE MakreFile的變量，方便我們的Makefile開發(fā)。比如：
我的Makefile，就使用了$(LINK.cc), $(COMPILE.cc)兩個宏。
#使用ACE的wrapper_macros.GNU的定義變量
include $(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
#得到C,CPP文件的列表
SRC_FILE = $(wildcard ./*.cpp )
#通過.C,.CPP文件名稱得到.O文件名稱，.o 文件放在../../object/exampleexe/目錄下
O_FILE = $(patsubst ./%.cpp, ../../object/exampleexe/%.o, $(CPP_FILE))
#輸出文件exe_file
OUTFILE = ../../bin/exampleexe
# LIB_ALL為 –l文件和-L目錄的定義
$(OUTFILE): $(O_FILE)
$(LINK.cc) -o$(OUTFILE) $(O_FILE) $(LIB_ALL)
#.o輸出文件放在../../object/目錄下
../../object/exampleexe/%.o : ./%.cpp
$(COMPILE.cc) $(INC_ALL) $< -o $@
clean:
$RM -f $(OUTFILE) $(O_FILE)
是不是也很酷，輕松實現(xiàn)Makefile的跨越平臺移植。
在文檔《ACE Programmer's Guide, The: Practical Design Patterns for Network and Systems Programming》中介紹了一種與位置無關(guān)的共享內(nèi)存分配，但是實際上這種方式并不是太理想。按照文章中的介紹的方式，其實主要是采用ALWAYS_FIXED參數(shù)，使用制定的基地址作為共享內(nèi)存的地址。同時使用輔助類保證2個進程使用相對地址使用共享內(nèi)存。
ACE_MMAP_Memory_Pool_Options options
(ACE_DEFAULT_BASE_ADDR,
ACE_MMAP_Memory_Pool_Options::ALWAYS_FIXED);
ACE_NEW_RETURN (g_allocator,
ALLOCATOR (BACKING_STORE,
BACKING_STORE,
&options),
-1);
ACE_DEBUG ((LM_DEBUG,
ACE_TEXT ("Mapped to base address %@\n"),
g_allocator->base_addr ()));
showRecords ();
但是，首先要求大家能使用相同的基地址，按照ACE給出的例子。其給出默認(rèn)基地址一個宏ACE_DEFAULT_BASE_ADDR(在Linux下是0x80000000)。因為地址空間管理都是操作系統(tǒng)的負(fù)責(zé)的事情，所以要求使用同一塊共享內(nèi)存的2個進程分配的基地址是一樣的是很不靠譜的事情。采用這種方式可能有2個后果，第一如果你要使用多個共享內(nèi)存，你要自己計算管理進程空間，第二你程序可移植性很低，甚至?xí)霈F(xiàn)在一臺機器上可以運行，在另外1臺機器無法運行。所以大家慎用這個特性比較好。把程序的可靠運行寄托于運氣好，這不應(yīng)該是一個程序員的作風(fēng)。
所以對于共享內(nèi)存，如果希望實現(xiàn)與位置無關(guān)的分配，我個人的忠告如下：
l 一開始分配足夠的空間，不要再進行擴展【注】。因為擴展共享內(nèi)存可能意味著原來所有的共享內(nèi)存相關(guān)指針會失效。
l 各自進程管理自己的地址空間，共享內(nèi)存內(nèi)部不要保存任何指針（特別不要在共享內(nèi)存內(nèi)保存指針），所有的地址都使用相對值。這樣才能保證重入，和基礎(chǔ)地址變化下不出現(xiàn)問題。
《ACE Programmer's Guide, The: Practical Design Patterns for Network and Systems Programming》中間還提出過處理共享內(nèi)存池封裝，但考慮到涉及所有的共享內(nèi)存地址的都要調(diào)整。不是太認(rèn)可這種方式。
另外由于ACE的容器都使用了指針，不建議在共享內(nèi)存中使用ACE的容器。
如果你的應(yīng)用有大量的定時器，你最好自己控制Timer_Queue的尺寸。原因如下。默認(rèn)的ACE的Timer_Queue初始化的尺寸不大，一般只有44個。而原有的尺寸不能滿足你的要求的時候，Timer_Queue會自動增長，以Timer_Heap為例，增長的方式是擴大一倍空間。在性能要求嚴(yán)格環(huán)境下，多次增長隊列的尺寸對性能會造成一定的沖擊。下面是空間調(diào)整函數(shù)grow_heap的部分代碼剖析。
template <class TYPE, class FUNCTOR, class ACE_LOCK> void
ACE_Timer_Heap_T<TYPE, FUNCTOR, ACE_LOCK>::grow_heap (void)
{
//調(diào)整為最大尺寸的兩倍
size_t new_size = this->max_size_ * 2;
ACE_Timer_Node_T<TYPE> **new_heap = 0;
//NEW新的空間，將原有的空間的數(shù)據(jù)拷貝回來。
ACE_NEW (new_heap,
ACE_Timer_Node_T<TYPE> *[new_size]);
ACE_OS::memcpy (new_heap,
this->heap_,
this->max_size_ * sizeof *new_heap);
delete [] this->heap_;
this->heap_ = new_heap;
//后面還有多個空間要擴展和調(diào)整
……
this->max_size_ = new_size;
}
其實這和std::vector一樣，如果你知道要使用多少空間，先調(diào)用reserve預(yù)分配空間會大大加快后面的執(zhí)行速度。如果你知道要使用多少個定時器，告知底層，它會幫你提前分配好空間，否則他會采用他認(rèn)為合理的方式和尺寸。
所以最好的方法是你先估算你大致需要使用的Timer數(shù)量，在初始化是告訴Timer_Queue。但是Reactor沒有辦法通過使用參數(shù)調(diào)整Time_Queue的大小，你必須自己進行替換Time_Queue來實現(xiàn)目的。方法大致如下：
ACE_Timer_Queue *timer_queue_=NULL;
//根據(jù)自己的需要調(diào)整Time_Queue的尺寸
timer_queue_ = new ACE_Timer_Heap(maxaccept + maxconnect + 16);
ACE_Reactor::instance(new ACE_Reactor(new ACE_Select_Reactor(NULL,timer_queue_,1),1),1);
這樣你就替換了Reactor的Timer_Queue，同時你要記住在程序運行退出前自己釋放的你申請的timer_queue_;
這一節(jié)列一些ACE使用中要注意的一些問題。
由于為了一些自己需要的特性，我一般會自己初始化ACE_Reactor，而不是讓系統(tǒng)默認(rèn)初始化。要注意必須在程序的最開始就初始化ACE_Reactor。
由于ACE的很多代碼都會使用ACE_Reactor，包括日志的策略類。所以ACE_Reactor必須在這些代碼前面，否則會出現(xiàn)奇怪的錯誤，比如無法響應(yīng)某些IO，我至少掉到這個陷阱里面5次。
有OO基礎(chǔ)的程序都會放資源的釋放放入析構(gòu)中間去。所以我看到ACE_SOCK_Stream也以為他的在析構(gòu)中關(guān)閉Socket的句柄，但是事實是ACE_SOCK_Stream必須自己顯式調(diào)用close函數(shù)關(guān)閉Socket句柄。
當(dāng)然，這倒不是ACE的設(shè)計缺陷，而是ACE的ACE_SOCK_Stream是一個可以出現(xiàn)在堆棧，可以作為參數(shù)傳遞，進行賦值的類，如果在析構(gòu)中關(guān)閉，就無法實現(xiàn)這些功能了。
實現(xiàn)決定設(shè)計。辨證呀。
Reactor的handle_events參數(shù)里面的有一個ACE_Time_Value參數(shù)，注意這個參數(shù)是一個傳入傳出參數(shù)。
virtual int handle_events (ACE_Time_Value &max_wait_time);
由于Reactor內(nèi)部同時要管理定時器和IO句柄，所以ACE很可能不能等待你制定的時間長度，所以他會在傳出參數(shù)告訴你剩余的等待時間。這時你可以讓ACE繼續(xù)等待剩余時間。但在主循環(huán)處理中，你不能這樣做，因為經(jīng)過多次調(diào)用后，ACE_Time_Value參數(shù)會變成0（ACE_Time_Value::zero）。這是會導(dǎo)致hanlde_events空轉(zhuǎn)，會導(dǎo)致CPU占用率很高。
對于大部分主循環(huán)的程序，都不需要這樣做，而應(yīng)該重新制定一個等待時間。
ACE_Singleton的模板參數(shù)是可以帶一個鎖參數(shù)的。
template <class TYPE, class ACE_LOCK>
class ACE_Singleton : public ACE_Cleanup
但你可能會錯誤理解這個鎖參數(shù)的用途。
typedef ACE_Singleton<Manager, ACE_Thread_Mutex> MANAGER;
MANAGER::instance()->ProcessFunA();
初學(xué)者可能會疑惑加鎖的是不是ProcessFunA，的處理被加鎖了。但是實際上ACE_Singleton的鎖只保護ACE_Singleton內(nèi)部的指針分配和銷毀不出現(xiàn)重入。也就是保護instance函數(shù)內(nèi)部的指針分配和釋放部分。代碼剖析如下：
template <class TYPE, class ACE_LOCK> TYPE *
ACE_Singleton<TYPE, ACE_LOCK>::instance (void)
{
//加鎖部分的代碼，使用GUARD方式保護new
ACE_GUARD_RETURN (ACE_LOCK, ace_mon, *lock, 0);
if (singleton == 0)
{
ACE_NEW_RETURN (singleton, (ACE_Singleton<TYPE, ACE_LOCK>), 0);
}
……
return &singleton->instance_;
}
其實理解函數(shù)棧調(diào)用的兄弟應(yīng)該很容易理解這個問題，ProcessFunA 函數(shù)入棧的時候instance函數(shù)已經(jīng)出棧了。instance函數(shù)內(nèi)部加（解）的鎖無法影響后續(xù)的調(diào)用。
這兒只是分析（猜測）一下ACE_DEBUG兩層括號的來由。用習(xí)慣了Windows下面跟蹤宏TRACE的人開始用ACE的調(diào)試宏ACE_DEBUG的宏都會有點不習(xí)慣，因為你必須寫兩層括號。
#if defined (ACE_NLOGGING)
#define ACE_DEBUG(X) do {} while (0) /*注意ACE定義的是(X)*/
#else
#define ACE_DEBUG(X) \
do { \
ACE_Log_Msg *ace___ = ACE_Log_Msg::instance (); \
ace___->log X; \ /*注意這兒，這個奇怪的寫法*/
} while (0)
#endif
//使用實例，
ACE_DEBUG((LM_ERROR,"i=%d.\n",i++));
比較起來，對于Windows下的TRACE宏的定義如下：
#ifdef _DEBUG
#define TRACE ATLTRACE
#else
#define TRACE __noop /* MSVC特有的一個標(biāo)識符，用于忽視后面的參數(shù) */
#endif
而ACE_DEBUG的定義比TRACE的定義是多一層(X)的，所以你必須寫兩層括號，ACE實際上將內(nèi)層括號的內(nèi)容全部作為宏參數(shù)使用了。
我曾經(jīng)對這兩層括號疑惑了很久。因為我覺得可以采用其他方法繞開兩個括號，（你可以寫一個日志類嘗試一下）
#if defined (ACE_NLOGGING)
// 直接定義為一個函數(shù)的名字，當(dāng)然這兒還要改寫其他的很多代碼
#define Z_DEBUG ACE_Log_Msg::instance ()->log
#else
#define Z_DEBUG
#endif
這樣的在沒有定義ACE_NLOGGING的時候，Z_DEBUG(LM_ERROR,"i=%d.\n",i++);會被替換成，(LM_ERROR,"i=%d.\n",i++)，這樣也不會有任何輸出效果。
直到有一次發(fā)現(xiàn)GCC2.9的環(huán)境下編譯類似代碼，GCC會對這樣的代碼會產(chǎn)生告警，我大致明白了ACE_DEBUG設(shè)計者的苦衷。只有雙層括號的方法才能徹底讓這行代碼不起任何告警。
另外使用兩層括號也有性能上的好處，大家注意代碼被替換成(LM_ERROR,"i=%d.\n",i++)后，i++的代碼還是要執(zhí)行，在我自己測試中，即使是在GCC的O3級別的優(yōu)化編譯中，這樣的代碼也不會被優(yōu)化掉。而如果采用ACE_DEBUG的設(shè)計，統(tǒng)一替換為do {} while (0)，這行代碼則必然將被優(yōu)化掉。而對于MSVC的編譯器，他提供一個特別的標(biāo)識符__noop幫助編譯器優(yōu)化。
大學(xué)畢業(yè)生中能成為好的程序員絕對不是純粹考試得高分死記公式拿獎學(xué)金的同學(xué) ，而是那些熬夜寫代碼的狂人，哈哈。
計算機是一門實踐科學(xué)，你只有不斷嘗試才能進步。
好像是Linus（雖然他好像有點抵觸C++，哈哈），好像是Linus Torvalds在回答一個提問者時說：“請去閱讀我的代碼”。了解一個實現(xiàn)，發(fā)現(xiàn)問題的最好方式還是閱讀源代碼。代碼面前，了無秘密。
當(dāng)然ACE的代碼閱讀起來不是一件那么舒心的事情。開發(fā)者們采用的是一些非常傳統(tǒng)的UNIX習(xí)慣，比如對齊方式采用2個空格縮進，單行if語句不用{}包含，稍顯奇特的inc文件方式，另外，為了支持跨平臺特性，ACE的代碼用了大量的宏。這都無疑增加了閱讀的難度。不過總體說了，ACE的代碼比較起Linux內(nèi)核代碼和很多其他類庫的代碼還是好的多，至少注釋很清晰，而且Doxgen生產(chǎn)的文檔很酷，也夠用。
由于ACE是一個跨平臺實現(xiàn)。如果你了解平臺的實現(xiàn)。不光你閱讀代碼的速度會快很多，也會讓你對實現(xiàn)的困惑就會越少，讓你的代碼避開效率的陷阱，你的實現(xiàn)就會越高效。
不需要OO的封裝，不用美妙的設(shè)計模式，沒有對效率的執(zhí)著追求，沒有驚艷的范化設(shè)計，用C++干什么？但沒有這些信仰，也就不會有ACE，而且沒有這些信仰要程序員做什么？
在ACE的使用過程中，發(fā)現(xiàn)ACE的主要問題出在一些高階實現(xiàn)上。所以如果你要使用高階特性最好能了解背后的實現(xiàn)。
多用ACE，將發(fā)現(xiàn)的問題反饋給ACE的開發(fā)者和ACE社區(qū)。
筆名：雁渡寒潭(insailer@gmail.com)
曾星 騰訊公司互動娛樂后臺開發(fā)程序員，目前從事游戲后臺設(shè)計開發(fā)
個人興趣范圍：大規(guī)模分布系統(tǒng)的架構(gòu)設(shè)計，高容量，大壓力的服務(wù)器設(shè)計；跨平臺開發(fā)；數(shù)據(jù)庫的設(shè)計，原理和調(diào)優(yōu)；多核（CPU）環(huán)境下的程序設(shè)計；OO和設(shè)計模式；C++和STL以及模板，ACE。歡迎大家交流。
表3 參考的文檔
|
參考書目
|
作者/譯者
|
說明
|
|
《C++ Network Programming Volume 1_Mastering Complexity With ACE and Patterns》
|
Douglas C. Schmidt, Stephen D. Huston
|
很多問題在這本書的副欄都有描述，如果你看的很認(rèn)真，也許不會想我這樣碰暗礁。
|
|
《C++網(wǎng)絡(luò)編程卷1：運用ACE和模式消除復(fù)雜性》
|
於春景
|
|
|
《C++ Network Programming Volume 2 - Systematic Reuse with ACE and Frameworks》
|
Douglas C. Schmidt, Stephen D. Huston
|
很多問題在這本書的副欄都有描述，如果你看的很認(rèn)真，也許不會想我這樣碰暗礁。
|
|
《C++網(wǎng)絡(luò)編程，卷2，基于ACE和框架的系統(tǒng)化復(fù)用》
|
馬維達
|
|
|
《The.ACE.Programmers.Guide》
|
Stephen D. Huston, James CE Johnson, Umar Syyid
|
|
|
《ACE程序員指南》
|
馬維達
|
|
|
《ACE自適配通信環(huán)境中文技術(shù)文檔》
|
馬維達
|
|
|
ACE html
|
ACE用Doxgen自動生成的文檔
|
|
此文檔是耗費兩年時間總結(jié)一些自己在使用ACE的7年中發(fā)現(xiàn)的一些問題，在湊夠了20個標(biāo)題后才進行發(fā)布。后面也許會根據(jù)自己的一些新的發(fā)現(xiàn)修正補充一下文檔，也許。
本著自由的精神，閱讀者可以無須授權(quán)就可以自由的轉(zhuǎn)載這個文檔，我只保留作者的署名權(quán)利，也就是說，你轉(zhuǎn)載只需保留這段說明和文檔的完整性（但你不能修改這個文檔，謝謝）。
這篇文檔也是為了回饋一下這些年來為自由軟件奮斗的人，也謝謝周圍陪我一起玩ACE 的Rong，Sonicmao，Awayfang等兄弟們。最后感謝一下Annie，她忍受了我整理文檔而不陪她看電視。