今天按照計劃把原型推翻重新寫了一遍，基本上還算順利，但還是有些問題花了我不少的時間。
首先是fork之後，父進程需要記錄子進程的pid，一遍在收到SIGCHLD信號時進行跟蹤管理，沒想到有時候子進程異常退出非常快，使得pid沒有被記錄到。雖然知道fork之後父子進程間的執行順序是沒有保證的，但是以前的應用可能不是很複雜吧。最後的方法是在子進程裏面先sleep(1)保證父進程先得到執行的機會。這可能最土的方法了，不過這個只是在初始化階段，對整個的影響不大。那位有更好的方法可以告訴我下，謝了。
reader和writer的同步採用改進後的方案後沒有什麼問題，但是新的問題是在執行load命令時只能關閉掉到mysql的鏈接才能使query語句返回，即使刪掉fifo文件也不頂用，不知道這算不算是mysql connector C的一個bug呢？明天有時間發帖子問下。但是判斷關閉連接的時間也是一個問題，因爲此時IB的loader可能正在工作，close掉鏈接的話可能使得部分數據丟失或者出錯。我打算做一個腳本來監控下，同時讓用戶自己選擇關閉整個應用系統。這個需要做到loader進程的自動化管理，因爲將來會有很多的reader進程，都是自動產生的。
今天還處理了下客戶那裏碰到的共享內存的問題，由於某個應用申請的共享內存超出了我們庫裏面提供的內存空間，導致應用初始化失敗。這個應用很變態，我不知道爲什麼一定要用我們的庫提供的封裝而不是直接調用系統的API，負責這個應用的Leader也不能說服我，但是這位老大又不願意更改。因爲馬上就到發佈了，改動太大對應的測試就是很多，很難保證高質量。我想了很久纔想到一種可能的解決方案，更改應用的內存佈局，使得我們的庫可以管理更多的內存空間，對Technique Leader講將來如果要將server移植到linux的話再將應用更到一個更加合理的設計上去。這個方案目前看來是唯一的快捷方式，也許是唯一可行的，短時間內。所以原型一弄完就得接着這個來。
傍晚TL來問我進展，我老實告訴他我今天沒有花什麼時間在上面，大部分時間在調試原型，不過已經快好了，等弄得差不多了立馬處理這個問題。TL的臉色顯得不大好看：剛從我手下離開，就不聽我的話了？呵呵！好在他還算是比較理解，答應我做完原型。半小時後總算是調試好原型，在wiki上吧上週沒有總結的IB的一些問題共享了一下。立馬開始調研這個問題，好在TL昨天給的網頁很有用，不然我查ld和gcc的手冊就得老半天了。明天得好好研究ELF和ld的script file，確認我的方案沒有問題。
快過年了，事情真多啊！