4. 消息传递进阶：MsgSendPulse、MsgError、通道与连接的生命周期管理

好，我们继续往下走。上一章我们把消息传递的基本套路讲清楚了——MsgSend、MsgReceive、MsgReply 这三板斧。但实际项目中，你总会遇到一些「不够用」的场景。

比如：我想发一个通知，但不需要对方回复，怎么办？或者，对方进程挂了，我的 MsgSend 卡死在那里，怎么处理？再比如，通道和连接到底什么时候创建、什么时候销毁，搞不好就内存泄漏或者进程崩溃。

这一章，我们就来啃这些硬骨头。

4.1 MsgSendPulse：轻量级的「通知」机制

先说说 MsgSendPulse。这玩意儿，说白了就是一个不需要回复的消息。

我刚开始用 QNX 的时候，总觉得消息传递必须是一问一答。后来做设备状态监控，发现有些场景根本不需要回复——比如定时心跳、状态刷新通知。你发过去，对方收到了就行，没必要等它回一句「我知道了」。

MsgSendPulse 就是干这个的。

4.1.1 为什么需要 Pulse？

你想想看，如果用普通的 MsgSend 发心跳，发送方必须阻塞等待回复。如果接收方处理慢了，发送方就被拖住了。这在实时系统里是很要命的。

Pulse 的语义是「发完即走」。发送方调用 MsgSendPulse 后，立即返回，不等待任何回复。接收方通过 MsgReceive 收到一个特殊类型的消息，处理完就完事。

核心区别：
  • MsgSend：阻塞等待回复，一问一答
  • MsgSendPulse：非阻塞，发完即走，单向通知

4.1.2 代码示例：发送 Pulse

#include <sys/neutrino.h>

int chid = ChannelCreate(0);
int coid = ConnectAttach(0, 0, chid, 0, 0);

// 发送一个 Pulse，代码为 1，数据为 0x42
struct _pulse pulse;
pulse.code   = _PULSE_CODE_MINAVAIL + 1;  // 自定义代码
pulse.value.sival_int = 0x42;

int ret = MsgSendPulse(coid, -1, pulse.code, pulse.value.sival_int);
if (ret == -1) {
    // 发送失败，比如对方进程已经挂了
    perror("MsgSendPulse failed");
}

接收方这边，用 MsgReceive 正常收消息就行。当收到一个 Pulse 时，rcvid 会是 0，表示这是一个脉冲消息，不需要回复。

struct _msg_info info;
struct _pulse pulse;

int rcvid = MsgReceive(chid, &pulse, sizeof(pulse), &info);
if (rcvid == 0) {
    // 这是一个 Pulse
    printf("收到 Pulse，代码: %d, 数据: %d\n", pulse.code, pulse.value.sival_int);
    // 注意：不需要 MsgReply，因为 Pulse 不需要回复
}
我的经验：Pulse 的代码范围有讲究。_PULSE_CODE_MINAVAIL 到 _PULSE_CODE_MAXAVAIL 是留给用户自定义的。别用 0 到 _PULSE_CODE_MINAVAIL - 1 的范围，那些是系统保留的，用了会出奇怪的问题。

4.2 MsgError：优雅地告诉对方「我出错了」

接下来聊 MsgError。这个函数，说实话，很多人容易忽略它。但我在项目中吃过它的亏。

有一次，我写一个资源管理器，客户端发来一个请求，我这边发现参数非法。当时我直接 MsgReply 返回一个错误码。结果客户端那边解析半天，发现数据格式不对，又重试，又报错，折腾了好久。

后来我才意识到，MsgError 才是处理这种场景的正确姿势。

4.2.1 MsgError 的语义

MsgError 的作用是：告诉发送方，你的请求我处理不了，并且给出一个错误码。发送方调用 MsgSend 后会立即返回 -1，errno 被设置为对应的错误码。

说白了，这就是一个「快速失败」机制。不需要构造复杂的回复数据，直接一个错误码扔回去。

// 接收方：检测到参数错误
if (参数非法) {
    MsgError(rcvid, EINVAL);  // 返回 "Invalid argument"
    return;
}

// 发送方：MsgSend 返回 -1，errno = EINVAL
int ret = MsgSend(coid, &msg, sizeof(msg), &reply, sizeof(reply));
if (ret == -1) {
    printf("请求失败，错误码: %d\n", errno);
}
注意：调用 MsgError 后，接收方不能再调用 MsgReply 或 MsgWrite。因为消息已经被「错误回复」了，再回复就是重复操作，会出问题。

4.2.2 什么时候用 MsgError？

我个人习惯是：

  • 参数校验失败：比如传入了无效的句柄、越界的索引
  • 权限不足：客户端没有足够的权限执行操作
  • 资源不可用：比如文件不存在、设备忙
  • 协议错误：消息格式不对，无法解析

这些场景下，用 MsgError 比构造一个错误响应结构体要简洁得多。而且发送方可以统一用 errno 来判断，代码更干净。

4.3 通道（Channel）与连接（Connection）的生命周期管理

好，重头戏来了。通道和连接，是 QNX 消息传递的基石。但很多人只学会了怎么创建，没学会怎么销毁。结果就是——资源泄漏、进程退出时崩溃、调试时一脸懵。

我见过最夸张的一次，一个服务进程创建了上千个通道没关闭，最后系统直接报「资源不足」挂了。

4.3.1 创建与销毁的对应关系

先记住一个原则：谁创建，谁销毁。

操作 创建函数 销毁函数
创建通道 ChannelCreate() ChannelDestroy()
创建连接 ConnectAttach() ConnectDetach()

看起来很简单对吧？但实际项目中，坑往往出在「谁负责销毁」这个问题上。

4.3.2 通道的生命周期

通道是接收方创建的。一个进程可以有多个通道，每个通道有一个唯一的 chid。

通道的生命周期：

  1. 创建：ChannelCreate(flags)，返回 chid
  2. 使用：MsgReceive(chid, ...) 接收消息
  3. 销毁：ChannelDestroy(chid)，释放资源
关键点：当通道被销毁时，所有等待在该通道上的 MsgReceive 调用会立即返回 -1，errno 设置为 EINTR。所有连接到这个通道的连接也会失效。

我曾经遇到过一个场景：服务进程在退出时，没有先销毁通道，而是直接 exit()。结果内核自动清理了通道，但客户端那边还拿着旧的 coid 在发消息，直接收到一个 ECONNRESET。嗯，虽然不会崩溃，但日志里一堆错误，看着很不爽。

4.3.3 连接的生命周期

连接是发送方创建的。一个连接对应一个 coid，指向某个进程的某个通道。

连接的生命周期：

  1. 创建：ConnectAttach(nd, pid, chid, index, flags)，返回 coid
  2. 使用：MsgSend(coid, ...) 发送消息
  3. 销毁：ConnectDetach(coid)，释放资源
我的建议：连接创建后，如果确定不再使用，一定要及时 ConnectDetach。特别是在循环中创建连接的场景，比如遍历多个服务，用完就拆，别攒着。

4.3.4 进程退出时的自动清理

QNX 内核很智能。当进程退出时，内核会自动：

  • 销毁该进程创建的所有通道
  • 断开该进程创建的所有连接
  • 通知所有等待在该通道上的接收方
  • 通知所有使用该连接的发送方

但别依赖这个自动清理。为什么呢？

第一，自动清理发生在进程退出时，如果你在运行过程中动态创建了很多通道和连接，不手动销毁，资源会一直占用。第二，自动清理不会通知你的业务逻辑，你可能会错过一些必要的善后处理。

所以我的习惯是：显式管理，显式销毁。在模块的初始化函数里创建，在反初始化函数里销毁。这样代码清晰，也不容易漏。

4.3.5 一个完整的生命周期示例

// 服务端
int server_init() {
    int chid = ChannelCreate(0);
    if (chid == -1) {
        perror("ChannelCreate failed");
        return -1;
    }
    return chid;
}

void server_cleanup(int chid) {
    if (chid != -1) {
        ChannelDestroy(chid);
    }
}

// 客户端
int client_connect(int server_pid, int server_chid) {
    int coid = ConnectAttach(0, server_pid, server_chid, 0, 0);
    if (coid == -1) {
        perror("ConnectAttach failed");
        return -1;
    }
    return coid;
}

void client_disconnect(int coid) {
    if (coid != -1) {
        ConnectDetach(coid);
    }
}
避坑指南：我曾经在代码里忘记调用 ConnectDetach，结果每次重连都创建一个新连接，旧的连接还挂着。系统里连接数越来越多，最后 ConnectAttach 返回 EMFILE（打开文件过多）。排查了半天才发现是连接泄漏。从那以后，我每次创建连接都会在代码里写上对应的销毁逻辑，确保成对出现。

4.4 本章小结

这一章我们聊了三件事：

  • MsgSendPulse：单向通知，发完即走，适合心跳、事件通知等场景
  • MsgError：快速失败，用错误码告诉发送方「不行」，比构造回复更高效
  • 通道与连接的生命周期：创建和销毁要成对出现，别依赖自动清理

这些知识点，单独看都不难。但组合在一起，就是 QNX 消息传递的进阶玩法。下一章，我们会聊更高级的话题——消息的优先级和紧急处理。到时候你会发现，Pulse 和 MsgError 这些基础能力，在复杂场景下会发挥大作用。

好，先到这里。有问题随时问我。

← 上一章 📖 返回目录 下一章 →