redis網路事件的特殊處理——stale event

在ae.c檔案的aeProcessEvents函數中，針對返回的網路事件有這樣的處理代碼：

int rfired = 0; /* note the fe->mask & mask & ... code: maybe an already processed  * event removed an element that fired and we still didn't  * processed, so we check if the event is still valid. */   if (fe->mask & mask & AE_READABLE) {          rfired = 1;          fe->rfileProc(eventLoop,fd,fe->clientData,mask);       }    if (fe->mask & mask & AE_WRITABLE) {          if (!rfired || fe->wfileProc != fe->rfileProc)               fe->wfileProc(eventLoop,fd,fe->clientData,mask);      }

第一感覺是不是很怪異？當某條串連上同時觸發了可讀和可寫回調，就只執行可讀回調(rfileProc)！

原因是因為clientData，在rfileProc中可能free掉clientData。這樣的話wfileProc處理就會coredump。

(請看redis-benchmark.c的readHandler，它有一句clientDone()調用回釋放掉clientData)

這樣的代碼有點像是在C++的類成員函數，裡面有一句delete this。。。基本屬於胡來行為

不得不說寫的真猥瑣噁心，資源管理非常混亂。

這也是有點厭惡C代碼的原因，放眼望去除nginx外，C代碼都醜陋不堪難以維護，

且都難以根治記憶體問題。

PS：nginx中也有類似的處理，美其名曰stale event。不多評論，我覺得是設計問題才導致了顧慮這麼多，弄出這些裝神弄鬼的東西。