mq_open失败报Invalid argument几乎全是struct mq_attr初始化错误：mq_maxmsg和mq_msgsize必须大于0且不超内核限制（/proc/sys/fs/mqueue/msg_max、msgsize_max），mq_flags必须为0，队列名须以/开头且不含其他/，mode应写为0644。
POSIX 消息队列在 C++ 中能直接用，但必须手动管理描述符、属性和生命周期；不处理 mq_notify 的重注册或空队列触发条件，异步通知会静默失效。
为什么 mq_open 失败常报 Invalid argument？
这几乎全是 struct mq_attr 初始化错误导致的。POSIX 要求 mq_maxmsg 和 mq_msgsize 必须大于 0，且不能超过内核限制（/proc/sys/fs/mqueue/msg_max 和 /proc/sys/fs/mqueue/msgsize_max）。
-
mq_flags字段必须为 0 —— 它是只读的运行时状态，传非零值直接触发 EINVAL - 若省略
&attr参数却用了O_CREAT，mq_open会用默认值（通常mq_maxmsg=10），但某些嵌入式系统默认值为 0，仍会失败 - 名称必须以
/开头且不含其他/，例如/myqueue合法，myqueue或/a/b都非法 - 权限 mode 建议显式写成
0644，避免八进制字面量被误解析（如644是十进制，0644才是八进制）
mq_send 和 mq_receive 的阻塞与超时怎么控？
默认行为是阻塞：发送方在队列满时挂起，接收方在队列空时挂起。生产环境几乎从不依赖默认阻塞，因为会卡死线程。
- 加
O_NONBLOCK到mq_open的oflag，后续所有mq_send/mq_receive都变非阻塞，失败时设errno = EAGAIN - 不改打开标志，也可用
mq_setattr动态切mq_flags的O_NONBLOCK位，但注意这不是原子操作，多线程下需同步 - 真正需要超时等待？POSIX 不提供带 timeout 的 recv/send，只能自己封装：用
poll()监听mqdes对应的文件描述符（需先调mq_fd = mq_getfd_np(mqdes)，但该函数非标准，仅 glibc 支持）
mq_notify 异步通知为何只触发一次？
这是最常被忽略的设计约束：mq_notify **仅在队列由空变非空时触发**，且注册后只生效一次。如果接收端没及时取走消息，后续来的新消息不会再次通知。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 必须在通知回调函数里立刻调用
mq_receive拿走消息，否则队列保持“非空”状态，通知永久失效 - 拿完消息后，必须重新调用
mq_notify注册同一回调，否则下次空→非空不再触发 -
sigev_notify_function运行在线程中，该线程默认栈空间极小（通常 8KB），传大结构体或递归调用易栈溢出 - 不要在回调里调
mq_close或mq_unlink—— 可能正被其他线程使用，应由主线程统一清理
System V 和 POSIX 消息队列该选哪个？
新项目无脑选 POSIX：mq_open("/myqueue", ...) 比 msgget(ftok("path", 'A'), ...) 更直观、无需文件路径依赖、支持优先级、自带异步通知。
- System V 的
msgsnd/msgrcv要求msg_type > 0，而 POSIX 的优先级是独立字段（mq_send(..., prio)），语义更清晰 - POSIX 队列名是纯内核标识（
/myqueue不占文件系统），System V 依赖key_t，容易因ftok输入路径不存在或权限问题生成冲突 key - 调试时，POSIX 队列可见于
/dev/mqueue/（需 root），System V 得靠ipcs -q，后者输出格式混乱且不显示消息内容 - 唯一例外：必须兼容老旧 AIX 或 Solaris 系统时，才考虑 System V
真正难的不是写通收发逻辑，而是确保 mq_notify 的重注册不漏、mq_unlink 不早于最后一个 mq_close、以及跨进程的 mtype 或优先级约定不出现类型混淆 —— 这些细节一旦出错，问题往往延迟暴露，排查成本远高于初始编码。
