Nginx的跨进程通信由master主导，worker通过Event Loop间接响应：master捕获信号并转为I/O事件（如自管道写入），worker在下一轮epoll_wait中处理，指令执行延迟取决于timeout设置与当前负载。
Nginx 的 Event Loop 本身不直接处理跨进程通信请求，它只负责单个 worker 进程内的事件调度。真正的跨进程通信（IPC）由 master 进程主导，worker 进程通过事件循环间接响应。
跨进程信号不会进入 worker 的 Event Loop
Unix 信号（如 SIGHUP、SIGUSR2、SIGQUIT）全部由 master 进程捕获，worker 进程默认屏蔽所有信号。这意味着：
- worker 不会因信号中断当前处理逻辑，也不会触发 epoll/kqueue 就绪事件；
- 所有配置重载、平滑升级、优雅退出等操作，都先在 master 中完成解析和准备，再通过 IPC 通知 worker；
- worker 只感知 master 发来的指令，而非原始信号。
IPC 指令被转为普通 I/O 事件交由 Event Loop 处理
Nginx 使用自管道（self-pipe trick）或 eventfd 实现 master → worker 的通知。这些机制本质是文件描述符上的可读事件：
- master 向管道或 eventfd 写入一个字节，触发该 fd 变为 EPOLLIN 就绪；
- worker 的 Event Loop 在下一次 epoll_wait 返回后，发现该 fd 就绪，调用预设的 handler（如 ngx_signal_handler）；
- handler 解析指令内容（例如“重载配置”或“关闭连接”），将其转化为内部动作（如 reload 配置结构、设置连接关闭标志）。
响应不是即时的，而是等待下一轮事件循环
worker 收到 IPC 指令后，并不立即执行，而是：
- 把指令存入内存状态（如 r->keepalive = 0 或 c->error = 1）；
- 注册或触发对应事件（如关闭连接时注册写事件并设置 timer）；
- 真正的动作（如发送 FIN、清理内存）发生在后续事件回调中，取决于当前负载和轮询间隔。
影响响应延迟的关键因素包括
- epoll_wait 的 timeout 设置：空闲时可能等待几十到几百毫秒才返回；
- 当前是否正在处理长耗时任务（如大文件同步写、阻塞模块调用），会推迟对 IPC 事件的检查；
- IPC 通道是否繁忙（多个指令堆积时，需逐个读取和解析）。
本质上，Nginx 把跨进程控制流“降级”为本进程内的 I/O 事件，复用已有 Event Loop 调度机制，既保证了架构简洁，又避免了信号处理的不确定性。
