之前了解过nginx中有陈旧事件，也知道是通过instance的标记位来区分陈旧事件，但一直没从根本上理解整个过程的运行以及nginx如何解决。这次读了一些资料和源码，对陈旧事件有了本质的理解。
先说为何在nginx中会有陈旧事件？
1 nginx通过epoll_wait返回了一组事件，比如返回了 #3 #5 #7 #9 #11 这些fd上都有事件触发，此时先处理#3，在处理3的过程中，如果发生了将 #9关闭的情况，此时如果nginx再去处理#9，就等于是一个不正确的操作。
这里再多说一句，nginx这里能够知道的就是event_list[i]数组，它处理event_list[3]后，即使event_list[3]关联的handler将event_list[9]对应的fd以及相关的连接c等结构体都释放了，nginx还是会遍历到event_list[9]。
如果只是上面这种情况，其实很好处理：event_list[9] 此时关联的c->fd已经为-1了【close】，即nginx判断是否fd为-1就能知道是否要处理。 【可以看到nginx也做了这个判断】
2 然而事件并不至于此
试想如果在处理event_list[7]事件时，它新建了一个连接，此时复用的刚好时之前#9占用的c连接，那这时候event_list[9]对应关联的c->fd就不是-1了，而是看上去是完全正常的【但此时已经完全和之前的情况不一样了】
此时nginx如何来判断该种场景？就是借助于这里的instance标记。
3 instance标记
上面第2种情况主要就是要解决，epoll返回过来的指向事件和实际的事件是否是同一个，因为在传入内核时(epoll_add)加入的rev肯定时需要处理的，但只是加入了将events->ptr指向了c地址，而c地址在服用场景下完全一样，不能看出啥区别，此时如果能够带入其他的一些信息给events->ptr这样就好了，那么就是 rev->instance标记，如果events能够记录到这个rev->instance标记，在wait返回时再取出来和现在遍历到的再做个比较就知道是不是同一个了。
但这里有个问题：events是个联合[union],此时ptr已经执行c了，没地方放rev->instance标记了，这里将c与rev->instance一起放在ptr里面！，是的由于ptr执行的c地址的最后一位肯定为0【地址对齐】，那这样最后一位用来存放rev->instance。
于是，从epoll_wait返回来后，再次将其取出，同时恢复c：
这样就能验明当时传入epoll的ev是否为此处的ev。
还有一个问题：为何rev->instance就能保持不变吗？原因是每次重新获取c时，其对应的rev的instance值总是会和上一次的rev的instance取反：
所以对于同一个slot的rev，其instance值总是在0、1、0、1之间变化
4 比较
这样通过上次rev->instance 和 本次rev->instance的标记，就能知道是否为陈旧事件：
如果一致，则rev依然为上次传入的，不过不一致，则是陈旧事件，是经过了复用后的。
5 最后
其实这种处理方式并不能100%杜绝掉陈旧事件，试想这样的场景： #3 #5 #7 #9 #11 #13
如果#3 关掉了#13的连接，#5此时建立连接复用了之前#13的连接，而处理#7时再次断掉了#13的连接，再处理#9时此次有重新建立了#13的复用连接。 这样经过了两次的关闭和重建，#13此时的连接对应rev->instance已经和之前的一致了，这样单从instance的一致性就区分不出来了。
不过这种概率极小，几乎不大可能发生，也就没有必要关注了。
感想：
发生这个问题的根源在于结构体的复用，即nginx里对连接/事件形成了池子，从池子里捞出来很有可能是刚放入进去的，所以需要小心区分。
