Exercise
5.1 只指定 mq_maxmsg 中的一个,未指定则使用默认值
struct mq_attr default_attr;
...........................
if (optind != argc - 1)
err_quit("usage: mqcreate [ -e ] [ -m maxmsg -z msgsize ] <name>");
mqd = Mq_open(argv[optind], flags, FILE_MODE, NULL);
Mq_getattr(mqd, &default_attr);
attr.mq_maxmsg = attr.mq_maxmsg ? attr.mq_maxmsg:default_attr.mq_maxmsg;
attr.mq_msgsize = attr.mq_msgsize ? attr.mq_msgsize:default_attr.mq_msgsize;
Mq_setattr(mqd, &attr, NULL);
未从 sysconf 中找到获取该项目的类型。
5.2 去掉 Figure5.5 中信号处理函数执行 mq_notify 的逻辑
只能收到第一条消息,第二条消息无法处理。mq_notify 注册的消息通知事件在被通知一次后会自动移除,在信号处理函数中不重新注册则无法捕获后续的事件。同时第二条消息还在队列中也不会触发通知事件,进程将一直空转。
5.3 去掉 Figure5.5 中信号处理函数执行 mq_receive 的逻辑
[longyu@debian:09:08:46] pxmsg $ ./mqnotifysig1 /test
SIGUSR1 received
只能收到一个 SIGUSR1 信号,由于不从队列中接收,只在投递第一条消息的时候会触发通知,后续消息由于队列不为空,尽管在信号处理程序中注册了 mq_notify,内核不会发送通知。
5.4 去掉 SIGRTMIN 宏前的 int 型强转操作的影响
debian11 中 SIGRTMIN 与 SIGRTMAX 宏定义如下:
365 /* Return number of available real-time signal with highest priority. */
366 extern int __libc_current_sigrtmin (void) __THROW;
367 /* Return number of available real-time signal with lowest priority. */
368 extern int __libc_current_sigrtmax (void) __THROW;
369
370 #define SIGRTMIN (__libc_current_sigrtmin ())
371 #define SIGRTMAX (__libc_current_sigrtmax ())
在我的 debian11 中测试去掉强转操作没有任何影响,编译不告警生成的程序也能够正常运行。
5.5 观察当前平台是否用内存映射 I/O 方式实现消息队列
debian11 中设定 mq_maxmsg 为 10 万时无法成功创建消息队列, 使用 root 用户设置 ulimit -q 也不能成功,strace 跟踪发现 mq_open 系统调用返回 -EINVAL,阅读代码找到如下相关内容:
ret = -EINVAL;
if (info->attr.mq_maxmsg <= 0 || info->attr.mq_msgsize <= 0)
goto out_inode;
if (capable(CAP_SYS_RESOURCE)) {
if (info->attr.mq_maxmsg > HARD_MSGMAX ||
info->attr.mq_msgsize > HARD_MSGSIZEMAX)
goto out_inode;
} else {
if (info->attr.mq_maxmsg > ipc_ns->mq_msg_max ||
info->attr.mq_msgsize > ipc_ns->mq_msgsize_max)
goto out_inode;
}
当设置了 SYS_RESOURCE capability 时,配置的 mq_maxmsg 不能超过 HARD_MSGMAX(65536),mq_msgsize 不能超过 HARD_MSGSIZEMAX(16M)。
相关宏定义如下:
#define DFLT_QUEUESMAX 256
#define MIN_MSGMAX 1
#define DFLT_MSG 10U
#define DFLT_MSGMAX 10
#define HARD_MSGMAX 65536
#define MIN_MSGSIZEMAX 128
#define DFLT_MSGSIZE 8192U
#define DFLT_MSGSIZEMAX 8192
#define HARD_MSGSIZEMAX (16*1024*1024)
ipc_ns 中的默认配置在 mq_init_ns 中初始化,此函数源码如下:
int mq_init_ns(struct ipc_namespace *ns)
{
struct vfsmount *m;
ns->mq_queues_count = 0;
ns->mq_queues_max = DFLT_QUEUESMAX;
ns->mq_msg_max = DFLT_MSGMAX;
ns->mq_msgsize_max = DFLT_MSGSIZEMAX;
ns->mq_msg_default = DFLT_MSG;
ns->mq_msgsize_default = DFLT_MSGSIZE;
m = mq_create_mount(ns);
if (IS_ERR(m))
return PTR_ERR(m);
ns->mq_mnt = m;
return 0;
}
默认最大的 mq_maxmsg 为 10,最大的 mq_msgsize 为 8192。
5.6 内存映射 I/O 实现中,mq_send memcpy 拷贝长度为 0 大小的消息
分析代码,接收者仍旧能够接收到这条消息,接收者的 memcpy 拷贝动作也不会执行,此实现在消息 len 为 0 时仍旧能够正常工作,linux 内核也有相同的行为,发送一个 len 为 0 的消息可以正常处理。
5.7 支持全双工通信需要创建几个消息队列?
需要创建两个消息队列
5.8 Figure 5.24 中为什么不销毁 mutex 与条件变量
munmap 函数并不会立刻释放内存,内部也有一个引用计数,只有当最后一个 munmap 被调用时内存才会真正释放。如果在 mq_close 中直接销毁位于共享内存中的互斥锁与条件变量,同时有人尝试访问时就会产生异常,因此代码中并没有主动销毁互斥锁与条件变量,它的销毁实际是在内核回收 mmap 映射的共享内存时进行的,此时不需要任何用户态干预动作。