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