Linux系统开发那点事儿 分享经验得牛人力作！（获奖名单已公布-2014-5-28）

duanjigang

以前搞了好几年的监控程序和多平台程序开发，对系统编程有一些感想：

(1) api 差别
   踩的坑多了，就开始留意标准 api 和系统 api的差别，以及便利性。比如：一开始你在linux下编程可能习惯
   打开文件使用open调用，当你尝试在windows平台编译你的程序时，或许会发现open调用并不存在，而需要调用_open等操作。
   最后，你会发现，某些时候，你只需要调用fopen,fread,fclose就能很好的处理这些问题。

(2) 多线程，多进程机制。
    编写多线程/多进程程序，难免会涉及到系统层面的API，也就是系统编程，因此，要开发并行程序，就需要在系统编程方面学习不少知识。

(3) 多平台程序
     接触多平台/多语言程序，就需要对不同平台，例如windows和linux上的程序运行环境，编译方法，运行库等进行深入了解，这也是学习系统编程的一个必然的途径。

(4) 内核/驱动开发
    参与一些windows下驱动程序，linux内核/驱动程序的开发，逐渐就会对系统编程的方法，注意点和差别积累起来经验。

以上是个人的一些感想好建议。

ruochen

进来膜拜下你们这些大牛

kensniper

mark 一下，回头有空再看

asdf2110

都是些小的知识点，但平时不注意就会出现问题

1. 多线程线程退出没有调用  pthread_destroy，时间长了发现内存泄露

2. 服务器内用 unixODBC 连接远程数据库，连不上服务器会一直连，长时间运行后发现有内存泄露
   最后看了下 unixODBC 源码，发现 unixODBC 内存泄露，有个地方 openXX 后失败直接返回，没有 closeXX

3. 程序 crash，堆栈落在国际化函数 gettext -> ... -> libc 中，原因未找到。

4. 读写文件时发生 IO Error 类错误，原因是使用了 direct io，要求 内存地址/文件偏移/读写长度 都要按扇区大小对齐，否则会报错

5. 调试 coredump 文件时，低版本的 gdb 看不到线程局部存储的变量，很郁闷（就是用 __thread 修饰的全局变量）

6. 分析性能问题时想知道程序堆栈，oprofile 貌似只能分析 debug 版的，可以借助 gdb 多次打印函数堆栈观察落点来分析 release 的

参考下面脚本，源自 RedHat系统自带的 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

复制代码

7. 一般 Linux 系统 ，一个进程的 fd 最多 1024（ulimit -n），遇到过服务器压力较大时，有8,9百个连接，socket + 文件，很容易就到了 1024，导致出现很多 too many open files 的错误
  启动服务器前加上 ulimit -n XXX 可以解决，如 ulimit -n 4096 && /etc/init.d/xxx start

2013sscc

膜拜大神，学习。

紫柳

做平台移植，从linux移植到MIPS平台，一个小端，一个大端。代码不是我写的，被坑的好惨好惨。。。

强制转换随便用，一转一个坑

连写的printf语句在单板上运行都能把程序整奔溃。

fedorayang

1.系统编程没有怎么写过，也没有怎么看过。现在在学习linux内核源码。
2.系统调用的许多函数都是标准库库提供的,在gcc编译生成,头文件也在gcc编译器目录下.
3.要想系统编程能力强，需要学习内核和驱动，系统编程就是使用内核提供的api

crazyhadoop

回复 47# fedorayang


    基本的都没用过，看内核代码有什么体会？

qianguozheng

linux开发中我多次调用fopen打开同一个文件时，文件描述符是递增的如 14,15,16等，通过fileno可以获得这个值，在关闭的时候注意了，要一一的关闭，不然问题可就严重了，会导致下次打开的文件时上次文件的描述符，如果还有进程在写上一个描述符的话，就会导致写错文件。
我之前写了个博客，详细阐述了这个问题：http://blog.csdn.net/qianguozheng/article/details/18745273

与天笑

1、不作死就不会死，写慢点没关系，对调用不熟悉的去man一下，注意看返回值和注意事项。
2、代码必须是无warning的。
3、划分好模块、组织好程序的数据结构和运行模型才是程序是否容易写、容易维护的关键。
4、慎用多线程，如果用到了，先去理解man 7 pthreads里的内容。
5、时刻记住保持程序的简单美和对称美。
6、写好log，做好测试。