Linux系統(tǒng)開發(fā)那點(diǎn)事兒 分享經(jīng)驗(yàn)得牛人力作�。ǐ@獎名單已公布-2014-5-28）

qingduo04

回復(fù) 27# 阿注哥


    呵呵，善意，代碼寫的很好啊

xike2002

好話題，支持一下。

justfaz

幫樓上補(bǔ)充2點(diǎn)（基本知識）
4、遞歸少用，能不用盡量不用
5、循環(huán)最好不要超過3層

pitonas

有一段時間了，都已不陌生了，
，linux 很強(qiáng)大�。�

AndyK_mengnan

需要的學(xué)習(xí)的東西 超多的

Soso_Boy

內(nèi)存溢出，線程死鎖，通訊失敗也就罷了！起碼還是自個兒代碼真正錯誤的地方，每一次修改都是華麗麗的升華！但是偶爾竟然會因?yàn)樵趇f（）后面多加了個分號而耗費(fèi)兩個小時檢查錯誤！我的手是有多賤��！怎一個慘字了得！

crazyhadoop

回復(fù) 37# Soso_Boy


    這不是坑，這是自己不仔細(xì)，哇咔咔，上一課

T-Bagwell

1. 系統(tǒng)開發(fā)中遇見的那些頭疼的問題
有時候主要是多進(jìn)程，多線程控制的問題相對來說比較頭疼，尤其是多進(jìn)程的進(jìn)程間通信，數(shù)據(jù)共享需要考慮，多線程的話需要考慮線程控制，線程鎖等問題，當(dāng)然有時候會使用多線程去做類似于多進(jìn)程的事，就是每個線程自己做自己的事；
有時候使用一些工具，腳本等，需要創(chuàng)建一個進(jìn)程去執(zhí)行
例如
fork()
exec() 去執(zhí)行，這么執(zhí)行以后，有些場景可能不需要wait，有些場景則需要wait，什么時候需要wait呢，當(dāng)需要獲得exec以后的結(jié)果，例如程序是否異常退出等；
尤其是組合上socket，例如在server部分希望執(zhí)行某個應(yīng)用程序，該程序執(zhí)行以后是否正常退出，將退出狀態(tài)反饋給client，這個時候wait就比較關(guān)鍵了；
如果client發(fā)了多次相關(guān)操作后，server執(zhí)行了多次相關(guān)操作呢？這個時候就要考慮pid的管理，當(dāng)然，更重要的是僵尸回收，這些需要考慮；
最后，綜合上面考慮，有人給出了一個比較時髦的東西——協(xié)程， 說白了，就是一個進(jìn)程，自己去實(shí)現(xiàn)自己的調(diào)度，而這個調(diào)度是單進(jìn)程單線程的，單進(jìn)程單線程比較蛋疼的是就是阻塞了，試想一下，一個進(jìn)程里面有多個任務(wù)，多個任務(wù)調(diào)度的時候有一個環(huán)節(jié)被阻塞住了，那么它就沒辦法進(jìn)入下一個任務(wù)了。
其實(shí)說白了，為了避免重復(fù)勞動，可以日積月累，自己搞一套方便自己的多進(jìn)程，多線程，協(xié)程的模型，這樣就爽呆了，就不會那么不靠譜了
提到socket，當(dāng)然還要考慮select/poll/epoll，也是要根據(jù)不同的場景去選擇，并不是所有的地方都epoll最好，有時候select其實(shí)也挺好用的，尤其是在某嵌入式平臺
        
2. 系統(tǒng)開發(fā)過程中的收獲
隨著系統(tǒng)開發(fā)的過程越來越多，積累的東西也越來越多，例如咋某種場景可以使用某種模型，可以很快的知道是用多進(jìn)程合適，還是用多線程合適，還是用協(xié)程合適。
當(dāng)然，以前只知道進(jìn)程，線程，后來又知道了協(xié)程
真是驗(yàn)證了那條 獨(dú)學(xué)而無有責(zé)鼓樓而寡聞啊

platinum

說一下編程優(yōu)化吧
這個水很深
比如當(dāng)你對一個二維數(shù)組賦值時，先循環(huán)“行”還是先循環(huán)“列”，執(zhí)行效率是完全不同的
這就涉及到了 CPU 的 cache
當(dāng)遇到 cache pingpong 時，cache 得不到最大發(fā)揮，就要頻繁讀寫內(nèi)存，程序執(zhí)行效率就會大幅度下降

給大家推薦個文檔，作者是：何登成

C 語言開發(fā)時，可優(yōu)化的地方很多，比如 inline 函數(shù)的使用，比如 readmostly，比如代碼的組織（盡量代碼段、數(shù)據(jù)集中）等。。。。。