MVC系統有三個子系統。Model 包含業務邏輯以及所有由系統處理的數據。它包括一個針對外部存儲（如一個數據庫）的接口。通常模型(model)只暴露一個公共的API給其它的組分。 View包含顯示數據的對象。Controller管理與用戶的交互（Controller處于Model和view中間）。在現代的UI工具包中，View和Controller組分是被集成在一起的。
上面的這段話是從《wxPython in action》中摘錄出來的，說的是GUI程序設計的模式。一個小小的軟件，為了讓它跑起來并順利完成相應的任務，折騰來折騰去。按照MVC模式，先把模型建立了起來：模型被單獨封裝成一個類，只向視圖與控制器提供開始、結束采集的命令傳輸接口以及一個用于數據傳輸的隊列（Queue.Queue類）。把只能執行一次的threading.Timer類改造了一下，構建了一個可以周期性執行的定時器。下位機還是用Arduino模擬（后面有時間的話，直接就用Arduino了，減少工序，有現成的就用現成的，盡量避免做從零開始寫程序、畫PCB、選購元件、焊接并調試電路板諸如此類的事情）。測試的時候沒有GUI的參與，只在腳本里面運行了一下，所以在主程序里面觸發了一個定時器，用來結束程序。啟動，等待程序結束，檢查數據庫。二十秒以內還好，停止命令發出后，程序可以退出，但是測量時間一長，程序就不能退出了。基礎不扎實，連程序到底運行到了哪里都弄不清楚。用IDE調試了半天，大概知道了有一個定時器沒有退出，但還是確定不了原因，再加上用于結束程序的定時器的干擾，動不動就拋異常。大概說一下，開始的時候構建出來的定時器是run函數遞歸調用自身，以此來實現周期性運行（秒級的，影響不是很大），這樣做的代價是大量函數進棧，停止時需逐層返回。后來改了下，不再借助遞歸了，耗費的資源應該會少一些。用trace跟蹤了一下，產生了四萬多行的跟蹤信息，重定向到txt文檔中后，文檔有兩兆多。跟蹤信息的最后一部分顯示程序還在threading里面游蕩，確實是自己構建的那個定時器沒有正常退出。找不到問題，就暫時扔下了。
費盡腦筋想的時候想不到，剛躺到床上立馬就意識到了問題出在哪里。可能就是那個Queue。由于沒有GUI參與，不需要繪圖，主程序里面沒有進行出隊列的操作，但處理數據的線程里面一直在進行入隊操作，Queue滿了以后，有可能把線程給阻塞了，所以線程無法退出。懶得起身開電腦了，在手機上的解釋器里面寫了幾句，發現隊列滿了之后確實會發生阻塞。看了一下python官方文檔，果然是這樣：
Insertion will block once this size has been reached, until queue items are consumed.
中午加了個python群，感覺太深入的問題沒有人回答，只能自己一遍一遍調試找癥節。獨自尋求解決方案的過程中確實能學到不少東西，但是，個中滋味恐怕也只有自己能體會。
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
