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。不多评论，我觉得是设计问题才导致了顾虑这么多，弄出这些装神弄鬼的东西。