| 听周君谈技术颇有听故事的感受，还恨不得立即整理成文。说来还要回溯到公司前身.....得，简单点，说今天吧。盯着屏幕上的"○●计费前置"程序清单，我可不敢怠慢，修改版马上要拿去上"生产环境"，出了差错将唯我是问，正当我字、句琢磨，停顿在 Fork 子进程处，看到子进程 Continue 负责侦听，而父进程却"处理来包"，感到分工有点反了似的。可这是经过"市场检验"的程序，这种特意安排一定有它的道理。"这样杜绝了僵尸进程的产生"-当程序最新版的作者尹某这样解释给我听时，一下子把我带到了在中南工大南院“封闭开发”的日子。在那间机器围成圈的会议室，正是肖工帮我解了急，他替我把程序中父进程和子进程干的活儿掉了个个儿，我虽然纳闷，看来却管用，的确用不着手工清理"僵尸进程"了！这个技术情结现在该有个了断了，于是我向开发部经理讨教，我说对这种技术处理有点"怪怪的"感觉，她说很早前就有张教授采用过这种方法，因此不是首创。周工也是这样解决了"僵尸进程问题"（对于谁的脑瓜里藏着什么绝招儿，开发部经理心有一本帐，她的"搜索引擎"准没错)。我没犹豫，问周君。周分析道：在 C 语言里父进程总是应该最后结束生命，如此它才有机会料理所有儿孙的"后事",只要在子进程中"安装"一个消息机制，出事故时向父进程通报，由指定的过程处理相关事宜，不仅能避免"僵尸进程"的产生，还能够统计在线的子进程数，并做一些必要的控制(例如断线续连等)。如果是反过来，父进程作为工作进程并匆匆离任，父子角色不断更迭，虽然巧妙地解决了"僵尸"问题(系统找不到父进程ID，就会主动善后),但放弃了对进程数量和业务处理的一些细节控制的可能性。因此，"父子易位"的技术处理，应相机采用。规范而高效的并发技术，值得大家商榷。
|