ftp 客戶端
以下情況程式有可能會掛掉（僅僅只是有可能）：
1. 伺服器關閉
2.大量資料猛的灌入
以下情況程式沒有問題，不會掛掉：
1.伺服器開啟，可以正常進行資料傳輸時
2.並行傳輸任務較少
3.資料灌入速度較慢
程式crush特徵：access violation at ox0000002 ；且出現完全隨機
場景1：
ftp客戶端開啟，伺服器關閉，以 平均50任務每秒的速度加入任務，從第一天下午5：30到第2天下午2：00，程式無任何異常；cpu, memory正常；
場景2：
測試環境同上，伺服器關閉，啟動時加入500任務，依次加入，執行至300左右時，crush。前後不足10s。
場景3：
同上，程式灌入任務，每10ms加入乙個單個任務，累計至1000任務左右時 crush.
場景4：
同上，手工灌入檔案，每次500個，累計灌入1萬檔案，程式ok
重點：隨機
除錯過程中的經驗：剛開始，有部分 共享資料沒有加鎖訪問，程式crush的機率非常大； 後來所有共享資料訪問，全部加鎖，程式crush機率大大降低，但仍然會掛掉；也帶來乙個不好的後果，加入介面使用者操作後，易死鎖，且隨機。
猜測錯誤根源：多執行緒的互操作，當某部分資料區已經消亡後，而其他執行緒繼續訪問時，便會出現如上的 access violation ；
現在的設計方案是：
mainthread 為介面執行緒，且 為每乙個檔案傳輸任務 建立 乙個 workthread；workthread是一系列的；
mainthread 維護乙個資料佇列，儲存每個檔案傳輸執行緒 ，也就是workthread的控制代碼；
workthread中實時更新 mainthread顯示資料；
workthread中實時更新資料佇列資訊；
mainthread 隨時訪問 workthread 資料；
mainthread控制workthread的建立，但workthread的loop完後自動銷毀；
執行緒間相互操作非常的繁雜；
修改設計如下：
workthread 絕不主動 callback mainthread 中的函式；
mainthread poll workthread ，然後實時更新介面資料；
mainthread 主動 join every workthread，並控制 workthread 的 create & destroy
明天就去嘗試。
一定要搞定這個問題！！！！
筆記 與bug硬剛的日子
本文紀錄若干工作過程中遇到過的bug，以及解決其的方法和感想等，作為筆記希望對諸位讀者有所幫助。筆者從事檢索系統相關的工作，那麼就會存在對評分的問題，比如當檢索詞為烏龜時，對於的url可能是，理應是有個字典，其中某個item是 烏龜 0.56 類似這樣的。然而，檢索過程中的url專案是不區分http...
戰鬥在國騰的日子 二 輝煌？
2000年是比較特殊的一年，怎麼特殊呢，很多個第一。第一次坐飛機出行，第一次出省，第一次出國，第一次公費旅遊，第一次旅遊消費過了5k n多個第一都發生在這一年的5月，因為效益還好，公司 此時專案屬華威資訊 組織員工集體出遊，目的地泰國，為期5天，公司出團費，據說是1800 人，5月1日出發。首先在公...
戰鬥bug技巧全攻略
程式設計師不是有一幅這樣的對聯嗎 上聯 乙個專案兩部電腦三餐盒飯只為四千工資搞得五臟俱損六神無主仍然七點起床八點開會處理九個漏洞十分辛苦 下聯 十年編碼九年加班八面無光忙的七竅生煙到頭六親不認五體投地依舊四肢痠軟三更加班只為二個臭錢一生孤苦 橫批 苦逼程式設計師。其實，程式設計師職業生涯總結起來就這...