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

duanjigang

以前搞了好幾年的監(jiān)控程序和多平臺(tái)程序開發(fā)，對系統(tǒng)編程有一些感想：

(1) api 差別
   踩的坑多了，就開始留意標(biāo)準(zhǔn) api 和系統(tǒng) api的差別，以及便利性。比如：一開始你在linux下編程可能習(xí)慣
   打開文件使用open調(diào)用，當(dāng)你嘗試在windows平臺(tái)編譯你的程序時(shí)，或許會(huì)發(fā)現(xiàn)open調(diào)用并不存在，而需要調(diào)用_open等操作。
   最后，你會(huì)發(fā)現(xiàn)，某些時(shí)候，你只需要調(diào)用fopen,fread,fclose就能很好的處理這些問題。

(2) 多線程，多進(jìn)程機(jī)制。
    編寫多線程/多進(jìn)程程序，難免會(huì)涉及到系統(tǒng)層面的API，也就是系統(tǒng)編程，因此，要開發(fā)并行程序，就需要在系統(tǒng)編程方面學(xué)習(xí)不少知識(shí)。

(3) 多平臺(tái)程序
     接觸多平臺(tái)/多語言程序，就需要對不同平臺(tái)，例如windows和linux上的程序運(yùn)行環(huán)境，編譯方法，運(yùn)行庫等進(jìn)行深入了解，這也是學(xué)習(xí)系統(tǒng)編程的一個(gè)必然的途徑。

(4) 內(nèi)核/驅(qū)動(dòng)開發(fā)
    參與一些windows下驅(qū)動(dòng)程序，linux內(nèi)核/驅(qū)動(dòng)程序的開發(fā)，逐漸就會(huì)對系統(tǒng)編程的方法，注意點(diǎn)和差別積累起來經(jīng)驗(yàn)。

以上是個(gè)人的一些感想好建議。

ruochen

進(jìn)來膜拜下你們這些大牛

kensniper

mark 一下，回頭有空再看

asdf2110

都是些小的知識(shí)點(diǎn)，但平時(shí)不注意就會(huì)出現(xiàn)問題

1. 多線程線程退出沒有調(diào)用  pthread_destroy，時(shí)間長了發(fā)現(xiàn)內(nèi)存泄露

2. 服務(wù)器內(nèi)用 unixODBC 連接遠(yuǎn)程數(shù)據(jù)庫，連不上服務(wù)器會(huì)一直連，長時(shí)間運(yùn)行后發(fā)現(xiàn)有內(nèi)存泄露
   最后看了下 unixODBC 源碼，發(fā)現(xiàn) unixODBC 內(nèi)存泄露，有個(gè)地方 openXX 后失敗直接返回，沒有 closeXX

3. 程序 crash，堆棧落在國際化函數(shù) gettext -> ... -> libc 中，原因未找到。

4. 讀寫文件時(shí)發(fā)生 IO Error 類錯(cuò)誤，原因是使用了 direct io，要求 內(nèi)存地址/文件偏移/讀寫長度 都要按扇區(qū)大小對齊，否則會(huì)報(bào)錯(cuò)

5. 調(diào)試 coredump 文件時(shí)，低版本的 gdb 看不到線程局部存儲(chǔ)的變量，很郁悶（就是用 __thread 修飾的全局變量）

6. 分析性能問題時(shí)想知道程序堆棧，oprofile 貌似只能分析 debug 版的，可以借助 gdb 多次打印函數(shù)堆棧觀察落點(diǎn)來分析 release 的

參考下面腳本，源自 RedHat系統(tǒng)自帶的 pstack

1. #!/bin/bash
   
2. pid=$1
   
3. for i in $(ls /proc/$pid/task)
   
4. do
   
5. echo "Thread $i"
   
6. gdb -p $i <<EOF 2>&1 |
   
7. bt
   
8. detach
   
9. EOF
   
10. sed -n -e 's/(gdb) //' -e '/^#/p' -e '/^  /p'
    
11. done

復(fù)制代碼

7. 一般 Linux 系統(tǒng) ，一個(gè)進(jìn)程的 fd 最多 1024（ulimit -n），遇到過服務(wù)器壓力較大時(shí)，有8,9百個(gè)連接，socket + 文件，很容易就到了 1024，導(dǎo)致出現(xiàn)很多 too many open files 的錯(cuò)誤
  啟動(dòng)服務(wù)器前加上 ulimit -n XXX 可以解決，如 ulimit -n 4096 && /etc/init.d/xxx start

2013sscc

膜拜大神，學(xué)習(xí)。

紫柳

做平臺(tái)移植，從linux移植到MIPS平臺(tái)，一個(gè)小端，一個(gè)大端。代碼不是我寫的，被坑的好慘好慘。。。

強(qiáng)制轉(zhuǎn)換隨便用，一轉(zhuǎn)一個(gè)坑

連寫的printf語句在單板上運(yùn)行都能把程序整奔潰。

fedorayang

1.系統(tǒng)編程沒有怎么寫過，也沒有怎么看過�，F(xiàn)在在學(xué)習(xí)linux內(nèi)核源碼。
2.系統(tǒng)調(diào)用的許多函數(shù)都是標(biāo)準(zhǔn)庫庫提供的,在gcc編譯生成,頭文件也在gcc編譯器目錄下.
3.要想系統(tǒng)編程能力強(qiáng)，需要學(xué)習(xí)內(nèi)核和驅(qū)動(dòng)，系統(tǒng)編程就是使用內(nèi)核提供的api

crazyhadoop

回復(fù) 47# fedorayang


    基本的都沒用過，看內(nèi)核代碼有什么體會(huì)？

qianguozheng

linux開發(fā)中我多次調(diào)用fopen打開同一個(gè)文件時(shí)，文件描述符是遞增的如 14,15,16等，通過fileno可以獲得這個(gè)值，在關(guān)閉的時(shí)候注意了，要一一的關(guān)閉，不然問題可就嚴(yán)重了，會(huì)導(dǎo)致下次打開的文件時(shí)上次文件的描述符，如果還有進(jìn)程在寫上一個(gè)描述符的話，就會(huì)導(dǎo)致寫錯(cuò)文件。
我之前寫了個(gè)博客，詳細(xì)闡述了這個(gè)問題：http://blog.csdn.net/qianguozheng/article/details/18745273

與天笑

1、不作死就不會(huì)死，寫慢點(diǎn)沒關(guān)系，對調(diào)用不熟悉的去man一下，注意看返回值和注意事項(xiàng)。
2、代碼必須是無warning的。
3、劃分好模塊、組織好程序的數(shù)據(jù)結(jié)構(gòu)和運(yùn)行模型才是程序是否容易寫、容易維護(hù)的關(guān)鍵。
4、慎用多線程，如果用到了，先去理解man 7 pthreads里的內(nèi)容。
5、時(shí)刻記住保持程序的簡單美和對稱美。
6、寫好log，做好測試。