Special Handling of redis network events-stale event

In the aeprocessevents function of the AE. c file, the following code is provided for handling the returned network events:

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);      }

First, is it weird? When both readable and writable Callbacks are triggered on a connection, only the readable callback (rfileproc) is executed )!

The reason is that clientdata may be free of clientdata in rfileproc. In this case, wfileproc will be coredump.

(See readhandler of the redis-benchmark.c, which has a clientdone () call back to release clientdata)

Such code is a bit like a class member function in C ++. There is a delete this... Basically belongs to Hu laibehavior

I have to say that writing is really cool, and resource management is very messy.

This is also why C code is a little disgusted. Apart from nginx, C code is ugly and difficult to maintain,

And it is difficult to solve the memory problem.

PS: similar processing is also available in nginx, which is called stale event. I don't think there are many comments. I think it is a design problem that has led to so many concerns.