题目起得有点大，这里加上POSIX只是为了说明本文描述并不是windows下的进程。

前几天遇到了一个问题，在terminal触发ctrl+c，也就是发送SIGINT信号后，程序的所有进程都收到了该信号，觉得有点奇怪，故收集并整理了相关资料。

本文为我的笔记，可能有不正确的点，望指正。

在绝大多数情况下，日志模块对于一个程序而言是必不可少的，对于服务端程序的重要性尤甚。

因为几乎所有服务端程序都是作为守护进程而运行的，因此指望开发者从terminal获取程序的状态并不现实，这个时候，依靠日志记录关键信息就很重要了，当然日志的作用远不止记录信息，它还可以用于恢复，相信从事数据库开发的读者对这应该十分熟悉，但这不属于本文的范畴。

对于Java开发者而言，他们是很幸福的，因为有log4j，甚至还有slf4j，而对于C语言而言，并没有发现同等地位或者功能的日志库，更别提类似slf4j之类的日志库抽象层了。于是，我拿起键盘，再次造起了轮子。

本文谈及的实现是为了多进程程序而设计的，简单而有效是我们追求的目标，通常而言简单的程序性能不会太差，当然乱用锁的除外。

赶在四月的最后一天，发篇有点营养的文章。

如何确保程序的正确性？这是一个很难的问题，答案是暂时没有。

在本站的很多篇文章中，我都说过测试并不可靠。因为测试的目标就是尽可能找出错误，测试用例越完善，覆盖度越高，能够找出的错误就越多。但问题就在于，一般情况下，测试用例的覆盖度根本达不到100%。

自创建这个博客以来，我一直在写一些技术类的文章，虽然写得不怎么样，但贵在坚持。

这几天突然觉得，如果一个博客没有主观性的思想，似乎少了什么，于是乎就有了本文。

在自动化验证技术成熟之前，我们依旧需要测试，能否编写优秀的模块，体现的是能力，而为代码编写完善的测试用例，体现的则是习惯。

虽然测试并不能说明什么问题，但目前我们并无任何备选方案，相信在很长一段时间内，完善的测试用例对于项目而言都是弥足珍贵的。

有些时候会觉得编写测试用例太烦，但是要知道，至少我们还能通过测试用例来进行测试，有很多领域是无法通过如此“傻瓜式”的测试来达成目的的。