回复 27# 阿注哥
呵呵，善意，代码写的很好啊
好话题，支持一下。
帮楼上补充2点（基本知识）
4、递归少用，能不用尽量不用
5、循环最好不要超过3层
有一段时间了，都已不陌生了，
，linux 很强大啊！:mrgreen:
需要的学习的东西 超多的
内存溢出，线程死锁，通讯失败也就罢了！起码还是自个儿代码真正错误的地方，每一次修改都是华丽丽的升华！但是偶尔竟然会因为在if（）后面多加了个分号而耗费两个小时检查错误！我的手是有多贱啊！怎一个惨字了得！
回复 37# Soso_Boy
这不是坑，这是自己不仔细，哇咔咔，上一课
1. 系统开发中遇见的那些头疼的问题
有时候主要是多进程，多线程控制的问题相对来说比较头疼，尤其是多进程的进程间通信，数据共享需要考虑，多线程的话需要考虑线程控制，线程锁等问题，当然有时候会使用多线程去做类似于多进程的事，就是每个线程自己做自己的事；
有时候使用一些工具，脚本等，需要创建一个进程去执行
例如
fork()
exec() 去执行，这么执行以后，有些场景可能不需要wait，有些场景则需要wait，什么时候需要wait呢，当需要获得exec以后的结果，例如程序是否异常退出等；
尤其是组合上socket，例如在server部分希望执行某个应用程序，该程序执行以后是否正常退出，将退出状态反馈给client，这个时候wait就比较关键了；
如果client发了多次相关操作后，server执行了多次相关操作呢？这个时候就要考虑pid的管理，当然，更重要的是僵尸回收，这些需要考虑；
最后，综合上面考虑，有人给出了一个比较时髦的东西——协程， 说白了，就是一个进程，自己去实现自己的调度，而这个调度是单进程单线程的，单进程单线程比较蛋疼的是就是阻塞了，试想一下，一个进程里面有多个任务，多个任务调度的时候有一个环节被阻塞住了，那么它就没办法进入下一个任务了。
其实说白了，为了避免重复劳动，可以日积月累，自己搞一套方便自己的多进程，多线程，协程的模型，这样就爽呆了，就不会那么不靠谱了
提到socket，当然还要考虑select/poll/epoll，也是要根据不同的场景去选择，并不是所有的地方都epoll最好，有时候select其实也挺好用的，尤其是在某嵌入式平台
2. 系统开发过程中的收获
随着系统开发的过程越来越多，积累的东西也越来越多，例如咋某种场景可以使用某种模型，可以很快的知道是用多进程合适，还是用多线程合适，还是用协程合适。
当然，以前只知道进程，线程，后来又知道了协程
真是验证了那条 独学而无有责鼓楼而寡闻啊
本帖最后由 platinum 于 2014-04-21 22:05 编辑
说一下编程优化吧
这个水很深
比如当你对一个二维数组赋值时，先循环“行”还是先循环“列”，执行效率是完全不同的
这就涉及到了 CPU 的 cache
当遇到 cache pingpong 时，cache 得不到最大发挥，就要频繁读写内存，程序执行效率就会大幅度下降
给大家推荐个文档，作者是：何登成
C 语言开发时，可优化的地方很多，比如 inline 函数的使用，比如 readmostly，比如代码的组织（尽量代码段、数据集中）等。。。。。