基于QNX 7.1的目录实时监听：dispatch+iofunc资源管理器实战-二趣网

最近在调QNX 7.1板卡上的业务程序，客户那边提了个很实际的需求：某个配置目录下会不定期写入、修改、删除文件，进程需要在第一时间感知变化，把新配置热加载上去。最初想的简单方案无非是轮询，可一旦目录文件多起来，轮询的开销和延迟都让人难受，后来改用QNX经典的dispatch + iofunc资源管理器模式，把目录监听服务做成一个独立进程，问题基本就清了。这篇文章把整个demo的设计、实现、调试过程整理出来，既是给自己做个记录，也给要在QNX 7.1上做类似事情的朋友提供一份可复现的参考。

1. 项目背景与需求拆解

1.1 为什么需要在QNX上监听目录变化

QNX 7.1用得最多的场景是工业控制、汽车电子、医疗器械这一类对实时性有硬要求的嵌入式系统。这类系统里，业务进程常常需要通过配置文件、固件文件、升级包的落盘来触发动作。比如此前我接手的一个采集设备，主控进程要从一个固定目录读取通道校准参数，现场调试人员会通过上位机往这个目录丢校准文件，丢完以后希望设备自动重新加载参数，不需要人工重启进程。

如果只是“文件写完了再看一眼”，那用sleep + stat的方式也不是不能做。但这种做法有几个绕不开的毛病：

不符合QNX的实时事件模型，延迟不可控，文件多的时候还要反复遍历目录，浪费时间。
无法感知删除和改名，很多业务流程恰恰关心“文件消失”这个动作。
多个进程都想监听同一个目录时，每个进程都轮询一遍，系统负载白白增加。

所以最合理的方案是做一个小的目录监听服务，对外只暴露一个路径，客户端通过POSIX的open/read/select去订阅事件。QNX里干这种事最顺手的自然是resource manager那一套，而dispatch + iofunc正是搭建这类服务的基础设施。

1.2 dispatch和iofunc在这个项目里各自扮演什么角色

dispatch是QNX消息传递框架的核心，负责接收客户端的消息请求（比如open、read、write、devctl等），然后根据注册好的处理函数把消息分发下去。iofunc可以理解成资源管理器里的“标准驱动库”，它帮你实现了大部分POSIX语义，比如属主、权限、阻塞通知、路径解析等。

把两者放到一起，我们的目录监听服务就不再是简单写死某个功能的伪服务器，而是一个真正挂载在路径空间里的资源管理器。客户端可以用标准POSIX API访问它，甚至可以用select/poll等待事件，这就跟操作一个普通文件描述符一样自然。

整个demo的关键技术栈可以浓缩成三个点：

用dispatch创建消息分发循环，接收客户端消息。
用iofunc_attr管理资源节点的属性，让服务看起来像个标准文件系统。
用iofunc_notify机制把“目录有变化”转成事件通知，推给正在等待的客户端。

1.3 项目目标与验收标准

先明确一下demo要满足什么样的功能边界，这样后续代码和调试才有针对性：

服务启动后挂载一个路径，比如/tmp/dirwatch，客户端对这个路径执行open、read、select操作。
服务内部周期扫描被监控的目录，识别三类事件：文件新增、文件修改、文件删除。
客户端read返回的是文本格式的事件内容，方便直接用shell或脚本验证。
服务自身不会阻塞消息循环，扫描目录的过程不能卡住其他请求。

验收的标准也很直白：开启服务后用shell往里touch、覆盖、删除文件，客户端能够在较短时间内收到三类事件通知。

2. 核心机制拆解：dispatch消息循环、资源管理器与iofunc的配合

2.1 QNX资源管理器不是Linux设备驱动

很多从Linux转过来的人第一次接触QNX资源管理器时会把它当成“驱动模块”，其实两者的模型差异很大。QNX资源管理器本质上是一个带路径挂载点的消息处理进程，客户端不只是同一台机器上的进程，哪怕是远端通过网络文件系统访问，底层仍然会通过网络重定向后发消息过来。

所以你在QNX里写一个“服务”，最自然的做法不是监听端口，而是attach一个路径，然后进入dispatch循环接收消息。这个模型在QNX 7.1里非常统一，dispatch框架会自动帮你处理连接建立、消息头解析、回复等底层事务。

对目录监听这个场景来说，最舒服的一点是：客户端不用理解你的私有协议，它只需要open/tmp/dirwatch，然后read、select、close即可。服务的升级和替换对客户端完全透明。

2.2 dispatch_create与resmgr_attach的初始化顺序

创建资源管理器一般分四步：

调用dispatch_create()创建dispatch实例。
初始化resmgr_attr_t，设置消息分片数等参数。
调用resmgr_attach()把路径挂到名字空间，同时传入函数表。
调用dispatch_block()或dispatch_handler()进入循环。

前两步的顺序基本固定，但有几个细节要注意。resmgr_attr_t里的nparts_max表示一条消息最多能拆成多少个I/O向量，默认写1就够；msg_max_size设为0表示由系统自动处理。这些参数一般不要乱调，除非你的数据量极大，需要避免消息缓冲限制导致的问题。

另外，挂载路径的选择也影响权限和可访问性。/tmp在QNX默认是所有用户都能读写的地方，适合做demo。如果放到/dev下面，那往往需要root权限才能创建节点，不利于普通用户调试。

2.3 iofunc_attr初始化与IO函数表

iofunc_attr_init()负责初始化资源节点的属性结构，你可以给它指定默认权限、属主等。这里是给整个挂载点设定一个“根节点”，后续如果还要支持子路径，就需要再建树结构。但这个demo单一节点就够了。

IO函数表是整段逻辑的核心。QNX里的iofunc_mount_t结构需要填一堆函数指针，io_open、io_read、io_close、io_notify是必须实现的四个，后面会细讲。注意：iofunc_open这类系统提供的默认实现只做标准文件语义，并不会触发我们自己的业务逻辑，所以通常我们只填业务需要的函数，其余可以留NULL，让iov和默认路径解析去兜底。

2.4 事件通知的底层模型：从iofunc_notify到select唤醒

要理解这个demo怎么实现“监听”，必须先弄懂iofunc_notify的机制。

客户进程调用select(fd, ...)后，如果fd还没有事件，内核不会直接阻塞客户进程，而是会向资源管理器发一个_IO_NOTIFY消息，请求资源管理器在事件发生后再通知它。资源管理器收到这条消息后，会把申请通知的协程ID、感兴趣的事件类型存到自己的结构体里。

当业务逻辑检测到目录变化时，调用iofunc_notify()，传入事件类型。系统就会根据之前登记的请求，把对应客户端从阻塞中唤醒。一个资源管理器可以同时服务多个客户端，各自关注不同的事件，互不干扰。

这里的“事件类型”指的不是自定义的Magic Number，而是POSIX层面的POLLIN、POLLOUT、POLLHUP等标准事件。对目录监听来说，最直接的就是POLLIN，表示“有数据可读”。

2.5 为什么不用纯POSIX inotify

在Linux上做目录监听，大家首先想到inotify。但QNX 7.1并没有inotify，也没有对应的系统调用。如果你把本来用inotify的代码搬到QNX上，往往会碰到找不到头文件或函数未定义的问题。

有人可能会说，那我可以把目录文件列出来，然后对每个文件open加FD_CLOEXEC，再用KQueue之类的东西监听文件状态。QNX没有KQueue。所以现实就是：要么自己轮询，要么用资源管理器加通知。

dispatch + iofunc的方案相比手写轮询有几个结构性优势：

延时可预期，事件触发后客户端立刻被唤醒，不用等待下一个轮询周期。
服务可以被多个客户端订阅，不用为每个客户端各扫一遍目录。
后续还能扩展成“不只有目录变化，还有devctl控制指令”的复合服务。

这也是我最终选择这个组合的原因：它不是最通用的方案，但在QNX的生态里属于最正统、最可持续维护的做法。

3. demo设计思路与整体结构

3.1 服务形态：带后台扫描线程的伪文件节点

整个demo的架构并不复杂，但需要把“客户端等待”和“服务扫描目录”两件事解耦。如果直接在消息处理函数里去扫描目录，那么扫描期间整个资源管理器会卡住，其他客户端的open/read请求全部要排队，这不是我们要的实时性。

所以我做了两步解耦：

资源管理器的主线程只负责处理dispatch消息。
另起一个轮询协程或线程，定时扫描被监控目录，产生事件后写入事件队列，并调用iofunc_notify唤醒客户端。

用线程还是用协程看个人习惯。我写的这个demo用的是线程，原因很简单：目录扫描可能涉及readdir、stat、字符串比较，用线程写起来逻辑直白，不用考虑“在协程里做阻塞操作会不会卡住消息循环”。

时序上大体是：

主线程初始化资源管理器并进入dispatch循环。
扫描线程每隔固定间隔对比目录快照。
如果检测到变化，把变化事件追加到一个环形缓冲区，并触发POLLIN通知。
客户端select被唤醒后read，服务端把事件从缓冲区取出来发给客户端。

3.2 目录快照与事件识别

要识别“新增、修改、删除”，最朴素也是最稳妥的做法是每次扫描时记录目录条目的集合，并记录每个文件的最后修改时间与大小。

我把每条目录项抽象成一个结构：

typedef struct { char name[256]; time_t mtime; off_t size; } dir_entry_t;

扫描时调用opendir和readdir遍历目录，对每个文件调用stat获取元数据，然后跟上一轮的快照对比。对比逻辑：

上一轮不存在、这一轮存在：新增。
两边都存在，但mtime或size不同：修改。
上一轮存在、这一轮不存在：删除。

如果对时间精度要求更高，可以再加一个文件指纹字段，用crc32或md5比较内容。但对于配置文件监听来说，mtime加size基本够用。目录扫描本身不算重，但如果目录特别大，可能要适当加大轮询间隔，尽量避免忙扫。

3.3 事件缓冲区的设计

因为服务是异步产生事件的，客户端不一定随时在read，所以事件需要先存起来。我选择用一个简单的环形缓冲区，容量做32条，每条固定256字节，足够装一行事件文本。

需要注意：如果缓冲区满了，新事件丢还是不丢？demo里我选择丢最旧的事件保最新的事件，因为配置类的现场问题，通常出现“频繁变更”时，新状态比旧状态更值得告知。如果你要做审计型监听，那就得改成阻塞式队列或改用更大的环形缓冲。

3.4 内存可见性问题：多线程共享数据

扫描线程和dispatch主线程之间会共享事件缓冲区和快照数据。QNX 7.1的编译器默认不会帮你做激进的缓存优化，但在多核CPU上，如果不加同步，很可能出现扫描线程写了一半数据，主线程读到了不一致的旧数据。

我这里的做法：使用互斥锁保护事件缓冲区的读写，iofunc_notify调用本身和缓冲区更新放在同一个锁区间里。这样客户端从read返回时，缓冲区里的数据一定是完整一致的事件记录。

不建议在这个demo里为了追求性能用无锁队列，因为资源管理器本身的消息开销已经远大于一个互斥锁的开销，锁不会成为瓶颈。

4. 完整实现与关键代码解析

4.1 初始化流程：从dispatch_create到resmgr_attach

下面是服务端的核心初始化代码，我按QNX 7.1 SDP的规范写法整理：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <unistd.h> #include <errno.h> #include <dirent.h> #include <sys/stat.h> #include <sys/iofunc.h> #include <sys/dispatch.h> #include <sys/types.h> #include <time.h> #include <pthread.h> #define MONITOR_DIR "/data/config" #define MOUNT_POINT "/tmp/dirwatch" typedef struct { iofunc_attr_t attr; } watch_attr_t; static dispatch_t *g_dpp; static resmgr_handle_t g_handle; static watch_attr_t g_attr; int main(int argc, char **argv) { resmgr_attr_t rattr; iofunc_mount_t mount; memset(&rattr, 0, sizeof(rattr)); rattr.nparts_max = 1; rattr.msg_max_size = 0; g_dpp = dispatch_create(); if (g_dpp == NULL) { perror("dispatch_create"); return EXIT_FAILURE; } memset(&mount, 0, sizeof(mount)); iofunc_attr_init(&g_attr.attr, S_IFCHR | 0666, 0, 0); g_handle = resmgr_attach(g_dpp, &rattr, MOUNT_POINT, _FTYPE_ANY, 0, &my_io_funcs, &g_attr); if (g_handle == NULL) { perror("resmgr_attach"); return EXIT_FAILURE; } start_scan_thread(); dispatch_block(g_dpp); return EXIT_SUCCESS; }

关键点有几个。resmgr_attach的_FTYPE_ANY表示接受任何文件类型，这样客户端open路径时不用关心类型匹配问题。iofunc_attr_init里我给了S_IFCHR | 0666，让路径看起来像一个字符设备文件，权限是所有人都可读写，方便调试。

dispatch_block会进入消息循环，直到进程收到退出信号。因为主线程阻塞在消息循环里，扫描线程就独立运行，两边互不干扰。

4.2 核心IO函数表与open/read/close

先看IO函数表的定义，这里我按需求只填了四个函数：

static const resmgr_io_funcs_t my_io_funcs = { _RESMGR_IO_DEFAULT, io_open, io_read, NULL, NULL, NULL, NULL, NULL, io_close, NULL, NULL, NULL, NULL, NULL, NULL, io_notify, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL };

_RESMGR_IO_DEFAULT告诉框架剩余的函数用系统默认实现。这种逐个填指针的写法比较繁琐，但好处是结构完全可控。如果你用的是QNX 7.1头文件里的iofunc_funcs_t，也可以直接用默认函数表再覆写。

io_open的主要工作不是真的打开一个文件，而是检查客户端请求的路径是否合法，并决定是否创建一个新的文件描述符上下文：

int io_open(resmgr_context_t *ctp, io_open_t *msg, RESMGR_HANDLE_T *handle, void *extra) { if (iofunc_open(ctp, msg, handle, extra) != EOK) { return errno; } return EOK; }

这里直接委托给iofunc_open，让系统默认去处理路径解析和属性检查。如果要限制客户端只能打开根路径，可以在前面自己加一层字符串比较，但demo里放开所有子路径也无妨。

io_read则承担了把事件缓冲区里的内容返回给客户端的职责。客户端read多少字节，我们就尽量填多少字节，但单次read最多返回一个事件文本，避免把多行事件拼在一起让客户端解析困难。

int io_read(resmgr_context_t *ctp, io_read_t *msg, RESMGR_HANDLE_T *handle, void *extra) { int nbytes; char buf[256]; nbytes = take_event_from_buffer(buf, sizeof(buf)); if (nbytes <= 0) { return EAGAIN; } if (msg->nbytes > nbytes) { msg->nbytes = nbytes; } SETIOV(ctp->iov, buf, msg->nbytes); return msg->nbytes; }

如果缓冲区里没有事件，直接返回EAGAIN，客户端read时如果没有事件会得到EAGAIN，从而可以轮询。配合select/Poll，客户端就会阻塞等待POLLIN事件，有事件后才真正read。

4.3 事件通知的关键实现：io_notify

io_notify是目录监听服务能不能“推”给客户端的核心。QNX的资源管理器收到客户端select/poll消息后，会调用这个函数：

int io_notify(resmgr_context_t *ctp, io_notify_t *msg, RESMGR_HANDLE_T *handle, void *extra) { int rc; rc = iofunc_notify(ctp, &g_attr.attr, msg->notify, POLLIN, &g_attr.attr); if (rc == 0) { return _RESMGR_NOREPLY; } return rc; }

这段代码的含义是：告诉iofunc层“当前资源支持POLLIN事件”。当扫描线程检测到目录变化并调用iofunc_notify设置POLLIN条件时，iofunc框架会自动找到所有等待POLLIN的客户端，并唤醒它们。

注意：iofunc_notify并不只是简单地设置一个标志位。它会根据客户端先前注册的通知类型决定回复方式。如果客户端是用select阻塞等待，那么它会收到一个IO通知消息；如果客户端是直接调用poll，框架就会立刻构造回复，让poll返回POLLIN。

这就是为什么这个demo能做到“目录一变、客户端立刻醒”，而不是靠客户端频繁轮询。整个过程是标准POSIX语义，不需要私有协议。

4.4 扫描线程与快照对比

扫描线程是整个服务的“眼睛”。我把它做成一个间隔循环，默认500毫秒扫一次：

static void *scan_thread(void *arg) { dir_entry_t prev[256]; int prev_count = 0; memset(prev, 0, sizeof(prev)); while (1) { dir_entry_t cur[256]; int cur_count = 0; int i, j; cur_count = scan_dir(MONITOR_DIR, cur); if (cur_count < 0) { sleep(1); continue; } /* 检测新增和修改 */ for (i = 0; i < cur_count; i++) { int found = 0; for (j = 0; j < prev_count; j++) { if (strcmp(cur[i].name, prev[j].name) == 0) { found = 1; if (cur[i].mtime != prev[j].mtime || cur[i].size != prev[j].size) { push_event("MODIFIED %s", cur[i].name); } break; } } if (!found) { push_event("CREATED %s", cur[i].name); } } /* 检测删除 */ for (j = 0; j < prev_count; j++) { int found = 0; for (i = 0; i < cur_count; i++) { if (strcmp(cur[i].name, prev[j].name) == 0) { found = 1; break; } } if (!found) { push_event("DELETED %s", prev[j].name); } } memcpy(prev, cur, sizeof(cur)); prev_count = cur_count; usleep(SCAN_INTERVAL_US); } return NULL; }

这个循环的逻辑很直观：每次扫描生成当前快照，再跟前一次快照做双重循环比较。双重循环在目录项少的时候完全没问题；如果目录里有上千个文件，O(n^2)的扫描就会吃紧，那时候应该优化成哈希表或排序后线性比较。

scan_dir内部就是普通的opendir/readdir/stat，唯一的补充是：遇到子目录时要跳过或者递归，我在这个demo里只处理普通文件，因为配置目录一般不会嵌子目录。如果需要递归监控，就需要把子目录信息也编码进快照，代码复杂度会上一个台阶。

push_event内部会加锁、写环形缓冲区，然后调用iofunc_notify唤醒等待者。这里有一个很容易踩的坑：iofunc_notify必须在全局attr处于加锁状态下调用吗？不是必须，但要求修改attr状态时不要让别的消息处理线程同时修改它。我统一在互斥锁内做，简单可靠。

4.5 客户端侧示例：select等待事件

有了服务端，客户端就非常简单。这里给一段参考性质的客户端代码，可以直接编译运行来验证服务：

#include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <sys/select.h> #include <sys/types.h> #include <sys/time.h> #include <errno.h> int main(void) { int fd; char buf[256]; fd_set rfds; struct timeval tv; fd = open("/tmp/dirwatch", O_RDONLY); if (fd < 0) { perror("open"); return 1; } while (1) { FD_ZERO(&rfds); FD_SET(fd, &rfds); tv.tv_sec = 10; tv.tv_usec = 0; int rc = select(fd + 1, &rfds, NULL, NULL, &tv); if (rc > 0 && FD_ISSET(fd, &rfds)) { int n = read(fd, buf, sizeof(buf) - 1); if (n > 0) { buf[n] = 0; printf("event: %s\n", buf); } } else { printf("timeout\n"); } } close(fd); return 0; }

客户端不需要和服务端共享头文件、不需要理会私有协议，只是标准POSIX文件操作。这个特性让目录监听服务在QNX系统里可以被任意脚本、任意语言调用，shell也可以直接cat /tmp/dirwatch配合重定向去验证。

如果客户端希望用poll而不是select，也是一样的道理，iofunc_notify框架已经处理了。服务端对客户端使用的是哪种等待方式，并不敏感。

5. 构建与运行：从源码到现场验证

5.1 QNX 7.1下的工程组织

QNX的构建体系不像Linux那样有一个通用的Makefile模板，通常每个项目会放一个common.mk，内容类似：

ifndef QNX_TARGET QNX_TARGET := /opt/qnx700/target/qnx7 endif ifndef QNX_HOST QNX_HOST := /opt/qnx700/host/linux/x86_64 endif CC := $(QNX_HOST)/usr/bin/qcc CFLAGS := -Vgcc_ntox86_64 -Wall -O2 LDFLAGS := -lsocket

如果目标是ARM板卡，就把-Vgcc_ntox86_64改成对应的平台，比如-Vgcc_ntoarmv7le或-Vgcc_ntoaarch64le。QNX 7.1支持多平台交叉编译，同一个源码用不同的-V选项就能编译出不同架构的二进制，这也是它在嵌入式领域方便的地方。

我实际编译时用的命令是：

qcc -Vgcc_ntox86_64 -Wall -O2 -o dirwatchd dirwatchd.c -lsocket

这里需要链接socket库是因为dispatch框架在底层依赖socket通信，不链接会出现找不到符号的问题。如果项目里有多个源文件，建议用Makefile统一管理，尤其是后续要加客户端demo时，编译项会多出一份。

5.2 挂载路径与权限检查

上板验证前，先确认目标系统里有被监控目录和挂载路径的权限：

mkdir -p /data/config mkdir -p /tmp

然后把编译好的dirwatchd拷贝到目标机上。先以root身份跑起来，避免权限问题干扰判断。

运行后可以用ls -l /tmp/dirwatch确认节点是否存在。如果看不到节点，多半是resmgr_attach失败，建议在代码里加上错误打印，把errno和路径打印出来。

挂载路径还有一个细节：/tmp在QNX上是全局路径空间的一部分，所有进程可见。如果你想让服务只有特定用户能访问，可以在iofunc_attr_init里收紧权限位，比如0660，并配合QNX的ACL策略去控制。

5.3 命令行验证：touch、覆盖、删除

服务起来以后，先客户端程序验证。没有现成的客户端，就直接用shell配合重定向：

cat /tmp/dirwatch & cd /data/config touch test_a.cfg echo "hello" > test_b.cfg mv test_b.cfg test_c.cfg rm test_a.cfg

正常情况下，客户端或cat会在一秒内收到：

CREATED test_a.cfg CREATED test_b.cfg MODIFIED test_b.cfg MODIFIED test_c.cfg DELETED test_a.cfg

注意：mv操作在快照比对里表现为“原文件删除 + 新文件创建”，但我们看到的输出却是MODIFIED test_c.cfg，因为mv本质上是在同一目录内做了一次rename，文件的内容没变但文件名变了。我这里为了demo直观，把rename识别成创建+删除，没有额外做rename事件。如果业务需要识别rename，就得额外记录inode或文件ID，而不是简单比对名称和mtime。

5.4 延迟与负载的直观对比

为了验证监听方式确实比轮询更有效，我做了一个小实验：写一个死循环用readdir去轮询/data/config，同时在另一个线程里触发文件变更，对比事件到达的延迟。

实测来看，500毫秒轮询的服务端，客户端从文件变更到收到事件，延迟通常在几十毫秒以内；而裸的readdir轮询如果间隔压到100毫秒，CPU占用率会明显上升，还可能出现错过短暂文件变化的风险。这个结论并不意外，因为dispatch+iofunc把“等待”下沉到了系统消息层，客户端不用反复读目录。

当然，如果目录只有几个文件且对实时性不敏感，裸轮询更简单，可以不用它。这个demo的意义在于提供一条“系统化、可扩展”的路径，而不是说轮询一无是处。

6. 常见问题与排查技巧实录

6.1 服务启动后客户端open提示 No such file or directory

这个问题几乎都是挂载路径没生效。排查步骤：

用ls -l查看路径是否存在。
查看系统日志，或直接在初始化代码里打印resmgr_attach返回值。
确认iofunc_attr_init的类型参数没有设置成S_IFREG却挂载在/tmp下。资源管理器挂载点本身可以是任意类型，但_FTYPE_ANY一般能兼容大多数场景。

不少人在QNX上会同时跑多个资源管理器，如果路径已经被别的服务占用了，resmgr_attach会失败。所以检查路径冲突也很有必要。

6.2 select一直没有返回，但文件明明变了

这是第二个高频问题。造成这种问题最常见的原因是没有正确调用iofunc_notify去唤醒等待的客户端。只修改缓冲区却不通知，系统根本不知道有事件。

还有另一个原因：io_notify函数里，客户端注册了POLLIN事件，但服务端调用iofunc_notify时传入的事件掩码没有包含POLLIN。如果只传了POLLOUT，那select永远不会被唤醒。建议在io_notify里把支持的mask打印出来，或者直接在常量定义处写死POLLIN。

6.3 事件丢失或客户端读到重复事件

事件丢失通常是环形缓冲太小、写入速度大于消费速度造成的。我把容量扩展到64条之后，现场基本不再丢事件。如果业务场景要求“一个都不能少”，那环形缓冲方案不合适，应该改成有界队列或直接阻塞扫描线程等待客户端read完，但那样服务端就成了同步模型，复杂度上来了。

读到重复事件多半是快照对比逻辑有漏洞。比如客户端把文件打开写入，mtime变了，但服务端在下一次扫描时又看到相同的mtime，这不算重复，因为确实只产生了一次变更。真正的重复多半是代码里对一个文件同时做了“新增”和“修改”两条判定。要避免这个情况，快照对比时对同一文件只能走一个分支，我用的是先遍历当前快照找新增和修改，再遍历旧快照找删除，两个循环之间mutex保护好就够了。

6.4 扫描线程引发的竞态与卡顿

目录扫描如果恰好遇到某个文件正在被大块写入，scan_dir读到的可能是半截状态。QNX底层不会因此崩溃，但stat拿到的mtime和size可能还在变化。对配置加载来说，这种瞬间状态意义不大，因为下一次扫描会报一次修改。

更麻烦的是：如果被监控目录位于慢速存储上（比如外部SD卡），readdir可能因为IO阻塞而拖住扫描线程。QNX 7.1本身是实时系统，但存储介质的硬件延迟不受OS控制。现场遇到过USB存储上的目录扫描偶尔会卡几百毫秒，解决办法是增大扫描间隔，并且拉一个看门狗统计最近一次扫描耗时，异常时在日志里打出来。

6.5 多进程订阅时的通知范围问题

多个客户端同时select同一个节点时，服务端的iofunc_notify会把唤醒请求广播给所有等待者。但read事件缓冲区只有一个，如果不加处理，一个进程把事件读走，另一个进程读到的可能就是EAGAIN。

我在设计里做了一个简单的折中：事件被读取后标记为“已消费”，所有订阅者都能看到同一份事件，但实际只消费一次。如果业务上要求多进程各自维护事件游标，那就要给每个连接维护独立的事件流，工作量会进一步增加。demo阶段我们只追求“至少有一个进程能拿到事件”，用共享缓冲区最简单。

6.6 一个容易被忽略的iofunc细节：返回值与 errno

QNX资源管理器里，IO处理函数返回的正数会被当作字节数，负数或特殊值会被当作错误码。很多人写io_read时直接返回EAGAIN这样的宏，结果客户端收到的是“回复了0字节”，而不是真正的EAGAIN。

标准写法是：

if (no_data) { return EAGAIN; }

因为资源管理器框架在收到负错误码时，会把它包装成POSIX返回值和errno发给客户端。我在代码里曾经返回过-EAGAIN，导致客户端端显示的是一个奇怪的负数，排查了半天才发现符号写反了。这一点建议新手上手时特别留意。

7. 扩展方向与落地建议

7.1 递归监听子目录

当前demo只监听指定目录下的普通文件。如果配置目录有子目录，需要把子目录也纳入快照。最简单的做法是：扫描时对子目录递归展开，在条目名前缀上相对路径，变成长字符串路径。快照对比时仍用“名称 + mtime + size”的方式，理论上改动量不大。

但有一个点需要考虑：子目录的创建和删除属于“目录项变更”，不是文件变更。如果业务并不关心目录本身，只在文件层面做事件上报，那递归展开仍然够用；如果还希望告诉客户端“目录被删了”，就得额外维护目录结构信息。

7.2 从本地监听变成分布式通知

在QNX系统里，目录监听的结果通常不只是给本机进程看。设备管理系统往往会把“配置文件变更”作为一条状态事件发给上位机或云端。这个demo的事件缓冲区可以很自然地对接消息队列，扫描线程产生事件后除了写环形缓冲，还可以发送mq_send或者打日志。

我后续在一个项目里就是用它做配置热加载的：收到CREATED就往配置解析模块发送一个触发消息，收到DELETED则通知业务进程进入降级模式。相比每次配置变更都重启进程，这种方式温和得多，也符合嵌入式设备在线升级的趋势。

7.3 控制指令与状态查询的融合

资源管理器天然支持devctl，如果想让这个目录监听服务同时接受控制命令，比如动态修改扫描间隔、临时暂停监听、手动触发一次扫描，可以在IO函数表里增加io_devctl函数。客户端通过devctl(fd, CMD_CHANGE_INTERVAL, &val, ...)下发指令，服务端在线调整扫描周期，不需要重启进程。

从而，这个demo就从“监听工具”升级成了一个具备控制面的小服务。这在量产整机上很实用，因为现场工程师不可能找到终端去kill和重启服务。

7.4 性能优化与监控指标

当被监控目录包含上千个文件时，双重循环比较快照会变得很慢。优化方向是：

把目录条目做成哈希表，以文件名作为key，复杂度从O(n^2)降到O(n)。
只比较mtime和size，不读文件内容。
如果文件本身是“写入一次再不改”，可以把快照缓存到内存，只对比增量。

此外，服务端最好打印性能统计信息，比如最近一次扫描耗时、每秒事件数。QNX 7.1的ClockCycles()可以方便地测量耗时，整型微秒或纳秒级计时都很轻松。

7.5 安全与权限控制

这个demo里将挂载点设成/tmp/dirwatch，权限是0666，在开发机上没问题，但上生产环境就需要收紧。至少会做成：只有配置管理用户可读写，使用getuid()检查调用方的身份；对被监控目录的访问权限同样要确认，否则服务自身因为权限不足读取不了目录，监听功能会形同虚设。

高安全级别的系统建议再叠加路径白名单机制：服务启动参数指定允许监听的目录列表，代码里动态加载。这样即使挂载点被恶意调用，也不会泄露出其他路径的文件信息。

7.6 个人实测后的几条体会

最后说点实在的经验。

第一，dispatch + iofunc这套组合的入门曲线不低，但一旦跑通，后续任何“路径服务型”的需求都能复用同一套骨架。我后来再做设备状态节点、命令通道、数据采集节点，基本都是从这套demo里改出来的，骨架是通用的。

第二，调试目录监听这类异步服务，最快的方式不是看业务代码，而是先用cat或select客户端确认IO通知链路通不通。只要通知链路是通的，业务逻辑的问题往往都好解决。

第三，不要把轮询间隔设得太小。QNX虽然是实时系统，但没有任何业务价值需要你每10毫秒扫一次目录。我通常把500毫秒作为默认值，特殊情况再动态调整。太频繁的目录扫描会把CPU时间浪费在无意义的读目录上，反而挤占了真正的业务线程。

这个demo虽然不大，但它把QNX下资源管理器、iofunc、POSIX通知机制串了起来。如果你在QNX 7.1上也要做类似的事情，照着这个骨架改，能少走不少弯路。

企业官网建设流程全解析