1. 引言 此前的文章中我们介绍了 tcpdump 的实用技巧： 实战计算机网络问题排查（二） -- tcpdump 的过滤指令 tcpdu

引言众所周知，C 语言相比于汇编语言拥有更为强大的灵活性和抽象能力，但相较于汇编语言，C 语言又缺乏了直接寻址、读写内存的强大能力同时，C 语言由于具备更强大的抽象能力，

概述阅读 nginx 源码接触到了一个新的系统调用 -- eventfdeventfd 系统调用是 linux 2.6 以上版本用来在用户空间创建可以用来作为事件等待、通知的文件描述符简单地说，就是可以在用户态应用中建立一个内核态到用户态的通知机制，这在异步 IO 的使用中非常有用但是该调用必须工作在 64 位环境下 函数原型int eventfd(unsigned int intval, int flag); 定义于 sys/eventfd.h 中调用成功返回文件描述符，调用失败，返回 -1 参数 flag 说明通过按位或运算可以使用以下一个或多个标识：eventfd 系统调用 flag 参数取值取值说明EFD_CLOEXEC类似于 open 系统调用的 O_CLOEXEC 标识，一旦 exec 执行后，关闭所有 fdEFD_NONBLOCK非阻塞调用EFD_SEMAPHORE以信号方式处理文件描述符，linux 2.6.26 以上版本将不支持 用法关于该系统调用的实际用法，可以参看 nginx 中的相应代码 var CODE_DIVS=[{"

问题描述开始阅读 nginx 源码的时候就一直伴随着一个问题，那就是多进程的 nginx 模型是怎么保证多个进程同时写入一个文件不发生数据交错呢？猜想中，主要有以下几种解决方案：最传统的，正在写文件的进程加锁，其他进程等待，但是这样的情况是绝对不允许的，效率太过低下写 log 前测试锁状态，如果已经锁定，则写入进程自己的缓冲区中，等待下次调用时同步缓冲区，这样做的好处是无需阻塞，提高了效率，但是就无法做到 log 的实时了，这样做工程中也是绝对无法接受的，一旦发生问题，将无法保证 log 是否已经被写入，因此很难定位一个进程专门负责写 log，其他进程通过域套接字或者管道将 log 内容发送给他，他持续阻塞在 epoll_wait 上，直到收到信息，立即写入，但是众所周知，nginx 是调用同一个函数启动所有进程的，并没有专门调用函数启动所谓的 log 进程，除了 master 和 worker，nginx 也确实没有 log 进程存在那么就是进程启动后，全部去竞争某个锁，竞争到该锁的 worker 执行 log&n

系统调用的重新启动信号发生的时刻，内核会中断正在执行的指令序列，跳转到信号处理函数中执行信号处理函数中如果没有使用exit或longjmp，当函数执行后会跳回捕捉到信号时正在执行的正常指令序列中，类似于硬件中断的处理方式但是被中断的系统调用并不一定是可以完全恢复的，比如对低速设备进行操作的时候被中断，因此在unix中引入了自动重启机制会被自动重启的系统调用有：ioctl、read、readv、write、writev、wait、waitpid因为应用程序并不是总是希望去重新启动这些系统调用，所以在不同的系统中的处理是不同的可重入函数在进程中，如果正在执行malloc操作进行堆空间的存储分配，此时插入执行信号处理函数会发生什么呢？又例如某些将结果存放到静态存储单元中的函数，期间插入执行信号处理程序，在程序中再次在静态存储单元中存放数据，这时会发生什么呢？上述的两种情况是不可重入的，因为内核维护的堆存储区链表可能正在更改，而第二种情况中存储区可能被覆盖 信号处理函数可以调用的可重入函数 acceptfchmodlseeksendtostat accessfchownlstatsetgidsymlink aio_errorfcntlmkdirsetpgidsysconf aio_returnfdatasyncmkfifosetsidtcdrain aio_suspendforkopens