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

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

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

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

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

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