前文再續，書接上一回。上次總結python錯誤碼返回與異常機制共用的一些原則，毫無疑問地，仍會出現程式不穩定的現象（好吧，可能是我個人能力問題）。在公司做的乙個專案中，出現了因為使用外部模組造成python程式記憶體暴漲直接崩潰的現象（被系統殺掉了，沒有返回memoryerror（估計是外部模組c程式碼的bug），簡單搜了下，可能使用記憶體限制模組可以在程式碼內解決這一問題（import resource），沒嘗試），由於估計是因為外部模組用到c寫程式碼造成崩潰，所以想到了用守護程序的形式去處理這個問題，而在寫好守護程序之後，為了方便，便用上了subprocess模組來做spawning。
就這樣走了點彎路，結果是，程式又變成了單次入口執行，多程序執行的樣子。隨即而來的，是日誌系統的問題。原來的日誌系統是單程序單日誌，而程序太多的話，便會造成大量分散的日誌文字。是沒有問題，但看著不舒服。如果用子程序的stdio直接和父程序互動的話，會出現日誌混亂。有待重新設計日誌系統啊=。=
在設計高穩定性的程式中，需要考慮的問題又多了乙個了，就是引用別人的模組時可能造成崩潰的情況。使用多程序的方法，輕鬆地把這個問題交給系統處理。在設計系統劃分模組的時候就要將那些可能出現問題的程式碼隔離開來（突然想到以前搞oi和acm的時候，測評機會是另外一台電腦，確保主伺服器的穩定性）。
python 程式穩定性閒談 續集
前文再續，書接上一回。上次總結python錯誤碼返回與異常機制共用的一些原則，毫無疑問地，仍會出現程式不穩定的現象 好吧，可能是我個人能力問題 在公司做的乙個專案中，出現了因為使用外部模組造成python程式記憶體暴漲直接崩潰的現象 被系統殺掉了，沒有返回memoryerror 估計是外部模組c程式...
關於程式穩定性
其實有的時候我們的程式需要乙個開關 當插上這個開關,造成乙個端子高電平 我們就認為是開了 然後通過timer裡計數,進行實時監測 當改了板子之後,新板子和原來相反,插上這個開關,造成乙個端子低電平 我們認為低電平是開機,這時程式需要改 但是我們可以設計乙個穩定的 程式,無論低電平使能,還是高電平使能...
mysql穩定性 MySQL的穩定性
isam表處理器 穩定 它管理所有在mysql 3.22和早期版本中的資料的儲存和檢索。在所有mysql版本中，中已經沒有乙個單獨 報告的 錯誤。得到乙個損壞的資料庫表的唯一已知方法是在乙個更新中途殺死伺服器，即使這樣也不大可能破壞任何資料而不能挽救，因為所有資料在每個查詢之間被倒入 flush 到...