Nginx 事件循环不支持信号量、定时任务优先级及抢占式调度；信号由 master 进程统一捕获分发，定时器基于红黑树按绝对时间排序，IO 事件始终优先于 timer，响应顺序取决于 epoll 就绪顺序与模块协作。
Nginx 的事件循环本身并不直接处理信号量（semaphore）或定时任务（timer），它也没有传统意义上的“优先级调度”机制。所谓“信号量”和“定时任务优先级”在 Nginx 中属于常见误解，实际实现方式与通用编程模型不同——理解这一点是避免踩坑的关键。
信号不是由事件循环“处理”，而是由主进程捕获并分发
Nginx 采用多进程模型（一个 master + 多个 worker），信号（如 SIGHUP、SIGUSR2、QUIT 等）由操作系统发送给进程组，但只有 master 进程 负责接收和解析信号；worker 进程默认屏蔽大部分信号（通过 sigprocmask），仅响应 master 显式转发的指令（如 reload 配置时的 ngx_signal_worker_processes）。
- worker 不直接响应 SIGTERM 或 SIGINT，而是等待 master 发送 quit 指令后优雅退出
- 自定义信号需通过 sigaction 在 master 中注册 handler，不能在 event loop 中“监听信号量”
- 所谓“信号量”（POSIX semaphore）在 Nginx 源码中几乎不出现，进程间同步靠共享内存 + 原子变量 + 文件锁（如 accept mutex）
定时任务本质是红黑树驱动的延迟事件，无优先级概念
Nginx 使用一棵按超时时间排序的红黑树（ngx_event_timer_rbtree）管理所有定时器，每个 timer 是一个 ngx_event_t 结构体。事件循环每次进入 epoll_wait（或其他 kqueue / select）前，先检查最近到期的 timer 是否已到时，然后执行其 handler。
- 所有定时器按绝对时间插入红黑树，查找最小超时值的时间复杂度为 O(log n)，不存在“高优先级 timer 插队”机制
- timer handler 运行在 worker 的主事件循环中，是同步、非抢占式的；若某个 handler 耗时过长（如阻塞 IO），会拖慢整个事件循环
- 添加 timer 使用 ngx_add_timer()，取消用 ngx_del_timer()；没有 set_priority() 或类似接口
真正影响响应及时性的，是事件类型与模块协作方式
虽然 Nginx 不提供显式优先级，但不同事件的实际响应顺序受以下因素隐式影响：
- IO 事件（accept/read/write）总是优先于 timer 事件：epoll 返回就绪事件后立即处理，timer 只在 epoll_wait 返回后、进入下一轮循环前检查
- 同一时刻多个就绪事件，处理顺序取决于 epoll 返回数组顺序（通常按就绪先后，但内核不保证严格 FIFO）
- 第三方模块若在 timer handler 中调用 ngx_http_post_request() 或触发子请求，可能间接提升某类逻辑的“感知优先级”，但这属于业务层编排，非内核级调度
需要“高优先级响应”？应转向架构设计而非修改事件循环
如果你遇到某些操作（如健康检查通知、紧急配置回滚）必须低延迟响应，Nginx 原生机制并不适合做实时调度：
- 将紧急控制面逻辑剥离出 worker，改用独立守护进程监听 Unix socket / HTTP 管理端口（如 nginx-module-vts 或自研 admin API）
- 对关键定时逻辑（如证书自动续期），使用外部 cron + nginx -s reload 组合，比依赖内部 timer 更可靠
- 若必须在 worker 内高频调度，可缩短 timer 间隔（如 100ms），但需配合 ngx_thread_pool 将耗时操作移出主循环，避免阻塞
不复杂但容易忽略：Nginx 的设计哲学是“简单、确定、可预测”，它主动放弃通用调度能力，换来的是极高的并发吞吐与稳定的延迟表现。想强行注入优先级语义，往往得不偿失。
