Nginx 的 EventLoop 不直接响应跨进程信号，信号由 master 进程统一捕获并经 IPC 通知 worker，后者在下次事件循环中处理，延迟主要来自轮询间隔、IPC 机制及任务负载。
Nginx 的 EventLoop 本身不直接处理跨进程信号通知，信号响应由主进程（master）负责，工作进程（worker）仅响应主进程通过进程间通信（IPC）转发的指令，因此“EventLoop 对跨进程信号的响应速度”这一说法存在概念混淆。
信号由 master 进程统一捕获
Nginx 遵循经典的 master-worker 架构。所有 Unix 信号（如
SIGHUP
、
SIGUSR2
、
QUIT
）均由 master 进程的信号处理函数捕获，worker 进程默认屏蔽绝大多数信号（通过
）。这意味着：
信号不会中断 worker 的 event loop，也不会触发 epoll/kqueue 的就绪事件；
worker 不感知原始信号，只接收 master 发来的 IPC 指令（如通过 socketpair 或 eventfd）；
master 收到信号后，需先完成自身逻辑（如重载配置、fork 新 worker），再向各 worker 发送命令。
worker 响应延迟主要来自 IPC 和事件轮询周期
worker 进程收到 master 的指令后，并非立即执行，而是将其转化为一个内部事件，等待下一次 event loop 迭代时处理。影响响应时间的关键因素包括：
event loop 轮询间隔
：在无活跃连接时，epoll_wait/kqueue 可能因 timeout 参数（如
或内核默认）而延迟数百毫秒才返回；
IPC 通知方式
：Nginx 使用自管道（self-pipe trick）或 eventfd 通知 worker，该 I/O 事件需被 epoll 监听并触发回调；
当前任务负载
：若 worker 正在处理长请求或阻塞操作（如 sync disk write、第三方模块阻塞调用），会推迟对 IPC 事件的响应。
可优化的实践点
若需提升配置重载、平滑升级等场景的响应一致性，可考虑：
设置
（或更小），减少空闲轮询延迟（注意增加 CPU 开销）；
避免在 worker 中执行阻塞系统调用，尤其在 init_worker_by_lua* 等钩子中；
使用
时，master 的 fork + sendmsg 流程本身有微秒级开销，通常可忽略，但高并发下大量 worker 会略微拉长整体传播时间；
监控
执行耗时（需 patch 或 perf 分析），确认是否因锁争用或回调堆积导致延迟。
本质上，Nginx 的信号响应不是“EventLoop 响应信号”，而是“master 解析信号 → IPC 通知 → worker 在下次事件循环中处理”。整个链路延迟通常在毫秒级，对绝大多数运维操作已足够及时，无需特殊优化，除非在超低延迟控制场景（如金融网关定制版）中做深度调优。
sigprocmasktimer_resolutiontimer_resolution 100msnginx -s reloadngx_process_events_and_timers()