cache_flush算是這個庫最糟糕的一段代碼了，總共有100多行，縮進(jìn)糟糕，做很多不同的工作。我就納悶，為什么不抽些子函數(shù)出來，這樣的代碼基本上不具備維護(hù)價值，因為自己重寫一次，比搞明白這個函數(shù)有趣多了。
由于這個函數(shù)實在太長，所以不一次全貼上來，一部分一部分的看吧。

首先，對 E.cache進(jìn)行排序，比較子是cache_node_cmp。
看return cb->parent - ca->parent ，是用 cb減去ca的，因此首先根據(jù)parent_id進(jìn)行降序排序。注意，在這一比較結(jié)果中，如果ca->parent = -1，那么比較結(jié)果為正，空閑節(jié)點ca往數(shù)組右邊移動；如果cb->parent = -1，那么比較結(jié)果為負(fù)，空閑節(jié)點cb還是會處在數(shù)組右邊。
為什么要注意這個呢？因為本次排序的一個結(jié)果就是，那些空閑節(jié)點都集中到了cache數(shù)組的右邊，只要遍歷cache的過程中遇到了第一個空閑節(jié)點，那么剩下的必然都是空閑節(jié)點了。
當(dāng)然要達(dá)成這個排序結(jié)果，還需要下面的這步，if (ca->parent == -1 ) {return 0;}
比較子的最后一句，在parent_id相同的情況下，按child_id升序排序。

E.cache經(jīng)過排序后，呈現(xiàn)出以下狀況：
1.根據(jù)parent_id呈降序排序，并且parent_id相同的節(jié)點緊挨在一起
2.空閑的cache節(jié)點全部都排在了數(shù)組的右邊
3.parent_id相同的節(jié)點，按child_id升序排序

排序之后，就是遍歷有序的cache數(shù)組。可以看到排序的效果了，當(dāng)parent_id = -1的時候，就只剩下空閑的cache_node，因此可以退出遍歷。

這一段代碼，是統(tǒng)計同一parent_id下child的數(shù)目。因為有些child_id被標(biāo)記了 UNSET_MASK，因此這種cache節(jié)點就不用統(tǒng)計到總數(shù)中了。其中UNSET_MASK_BIT是位移操作，如果child被標(biāo)記了UNSET_MASK，那么位移的結(jié)果就是1，1-1=0，也就沒有統(tǒng)計到總數(shù)中了。

統(tǒng)計了parent擁有的child之后，接下來就是要把這些child記錄到parent的數(shù)據(jù)結(jié)構(gòu)上了。這里不得不回顧一下struct node的定義，上次看的時候，并沒有探討struct link *children是做什么的，現(xiàn)在可以看看link的定義
這個結(jié)構(gòu)就是parent用來記錄其所有child_id的地方。其中number用來記錄child的總數(shù)量，而children則是一個整數(shù)數(shù)組，用來記錄所有的child_id。
cache_flush剩下的操作，就是把新的child_id添加到children中去，當(dāng)然其中包含其他一些細(xì)節(jié)處理。這里先把這些東西交代清楚，因為其后的代碼將是比較難以理解的，我仍不是十分的明白。