消息队列（也叫做报文队列）能够克服早期unix通信机制的一些缺点。信号这种通信方式更像\"即时\"的通信方式，它要求接受信号的进程在某个时间范围内对信号做出反应，因此该信号最多在接受信号进程的生命周期内才有意义，信号所传递的信息是接近于随进程持续的概念（process-persistent）；管道及有名管道则是典型的随进程持续IPC，并且，只能传送无格式的字节流无疑会给应用程序开发带来不便，另外，它的缓冲区大小也受到限制消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。
mq_open - 打开一个消息队列
概要
#include <fcntl.h> /* 定义 了O_* 常量 */
#include <sys/stat.h> /* 定义了 mode 常量 */
#include <mqueue.h>
mqd_t mq_open(const char *name, int oflag);
mqd_t mq_open(const char *name, int oflag, mode_t mode, struct mq_attr *attr);
需要 -lrt 来链接。
描述
mq_open() 创建一个新的 POSIX 消息队列或打开一个存在的队列。这个队列使用 name 标识。每个消息队列都通过形如/somename 的名字来区分，这是一个包含起始斜杠在内的最大长度不超过 NAME_MAX(如 225)的以空字符结尾的字符串，在起始斜杠之后不允许再有斜杠。
参数 oflag 参数指定控制操作的标志。(这个标志的值可以通过包含 <fcntl.h> 来获得。)下面给出的标志至少需要指定一个：
O_RDONLY 以只能收取消息的方式打开队列。 O_WRONLY 以只能发送消息的方式打开的队列。 O_RDWR 以可发送也可收取消息的方式打开队列。
零个或多个下面列出的标志可以用 位或 到 oflag 里：
O_NONBLOCK 以非阻塞的方式打开队列。具体情况是在 mq_receive(3) 和 mq_send(3) 要阻塞的时候，这些函数使用错误 EAGAIN来替代。 O_CREAT 如果不存在则创建消息队列。消息队列的所有者(用户 ID)被设置为调用进程的有效用名 ID。组属性(组 ID)被设置为调用进程的有效组 ID。 O_EXCL 如果 O_CREAT 在 oflag 里指定，当名为 name 队列已经存在时，让函数以 EEXIST 失败。
如果 O_CREAT 在 oflag 里指定，那么两个额外的参数也必须给定。mode 参数指定新队列的权限，这与 open(2) 一样。(描述权限的符号常量可以通过包含 <sys/stat.h> 来获得。)权限设置会被进程掩码处理。参数 attr 指定队列的属性。参考 mq_getattr(3) 来了解细节。如果 attr 是 NULL，队列将使用实现定义的默认属性来创建。
返回值
成功时，mq_open() 返回一个能被其它消息队列函数使用的消息队列描述符。失败时，mq_open() 返回 (mqd_t) -1，并设置errno 来指明错误。
错误 EACCES 队列存在，但是调用者没有权限以指定的方式打开。 EACCES name 包含多个斜杠。 EEXIST 在 oflag 里同时指定了O_CREAT 和 O_EXCL，但是名字 name 的队列已经存在。 EINVAL O_CREAT 在 oflag 里存在，并且 attr 不是 NULL，但是 attr->mq_maxmsg 或 attr->mq_msqsize 是无效的。这两个域都必须大于零。对于一个非特权(没有 CAP_SYS_RESOURCE 能力)进程attr->mq_maxmsg 必须小于或等于 msg_max 限制，并且 attr->mq_msgsize 也必须小于或等于 msgsize_max 限制。此外，就算是特权进程，attr->mq_maxmsg 也不能超过 HARD_MAX 限制。(参看 mq_overview(7) 了解限制的更多细节。) EMFILE 进程已经达到打开的文件和消息队列的最大数目。 ENAMETOOLONG name 太长了。 ENFILE 达到系统允许打开文件个数和消息队列的全局上限。 ENOENT O_CREAT 没有在 oflag 里指定，并且没有名字 name 的队列存在。 ENOENT name 只是 "/" 而没有其它字符。 ENOMEM 内存不足。 ENOSPC 没有足够的内存来创建新的消息队列。这个可能是因为达到 queues_max 限制而引起的，参考 mq_overview(7)。
mq_close - 关闭一个消息队列描述符
概要#include <mqueue.h> int mq_close(mqd_t mqdes);
需要 -lrt 来链接。
描述
mq_close() 关闭消息队列描述符 mqdes。
如果调用进程在消息队列 mqdes 绑定了通知请求，那么这个请求被删除，此后其它进程就可以绑定通知请求到此消息队列。
返回值
成功时，mq_close() 返回 0；错误时，返回 -1，并把 errno 设置为合适的值。
错误 EBADF mqdes 指定的描述符无效。
需要 -lrt 来链接。
mq_getattr() 在 attr 指向的内存里返回一个 mq_attr 结构体。这个结构定义为：
mq_flags 的域包含打开消息队列描述符相关的标志。这个标志由 mq_open(3) 初始化。能存在于这个标志的域只有 O_NONBLOCK。
mq_maxmsg 和 mq_msgsize 两个域由 mq_open(3) 在队列创建时设置的。mq_maxmsg 是使用 mq_sen(3) 发送数据大小的上限。mq_msgsize 是当前队列可以缓存消息个数的上限。用于设置这些域的软上限的两个 /proc 文件在 mq_open(3) 中有描述。
mq_curmsgs 域用于返回当前队列里已经有消息个数。
mq_setattr() 设置消息队列的属性，设置时使用由 newattr 指针指向的 mq_attr 结构的信息。属性中只有标志 mq_flasgs 里的O_NONBLOCK 标志可以更改，其它在 newattr 内的域都被忽略。如果 oldattr 不是空指针，那么它指向的内存用于返回现有的属性结构mq_attr，此时包含信息与通过 mq_getattr() 取得的信息相同。
需要 -lrt 来链接。
sevp 参数是一个指向 sigevent 结构的指针。关于这个结构的定义与相关细节，见 sigevent(7)。
如果 sevp 是一个非空指针，那么 mq_notify() 注册调用进程以在消息到达时收到通知。sevp 指向的 sigevent 结构中的 sigev_notify域用于指明通知的方式。这个域可以有如下几个值：
对于一个消息队列只能有一个进程可以注册到达通知。
如果 sevp 是 NULL，并且调用进程当前已经在相应的队列里注册过通知，则这个注册被删除；此后其它进程就可以注册到这个队列里以接收通知。
消息通知只有在一个新消息到达且之前队列是空的情况下被递送。如果 mq_notify() 调用时队列非空，则通知会在队列变空之后且有新消息到达时递送。
如果其它进程或线程正在通过 mq_receive(3) 等待一个空队列的消息到达，则任何新到达的消息都被忽略：这些消息会传递给调用mq_receive(3) 进程或线程，而消息通知注册仍然有效。
通知只发生一次：在一个通知递送之后，这个通知注册会被删除，并且其它进程可以注册一个通知。如果收到消息的进程想接收下一个通知，它可能使用 mq_notify() 请求一个全新通知。这可以在所有未读消息被收到完之前来执行。(此时把队列设置非阻塞模式会很有用，在清空队列消息的时候而不用担心一旦队列变空之后被阻塞。)
POSIX.1-2008 说当 sevp 是 NULL 时，实现可以产生一个 EINVAL 错误，并且调用进程不会被注册到队列 mqdes 的通知里。
mq_send, mq_timedsend - 发送一个消息到消息队列
#include <mqueue.h>
int mq_send(mqd_t mqdes, const char *msg_ptr, size_t msg_len, unsigned msg_prio); #include <time.h>
#include <mqueue.h>
int mq_timedsend(mqd_t mqdes, const char *msg_ptr, size_t msg_len, unsigned msg_prio, const struct timespec *abs_timeout);
需要 -lrt 来链接。
glibc 需要特性测试宏(参看 feature_test_macros(7))：
mq_timedsend()：
_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L
mq_send() 把 msg_ptr 指向的消息加入由 mqdes 引用的消息队列里。参数 msg_len 指定消息 msg_ptr 的长度：这个长度必须小于或等于队列 mq_msgsize 属性的值。零长度的消息是允许。
msg_prio 是一个用于指定消息优先级的非负整数。消息在队列里依据优先级排序，相同优先级的消息新消息放于旧消息后面。
如果消息队列已经满了(如当前队列消息个数等于队列的 mq_maxmsg 属性)，那么，默认地，mq_send() 会一直阻塞到有足够的空间来把当前消息入队，或者在阻塞的时候被一个信号处理器中断。如果 O_NONBLOCK 标志在消息队列描述符里有设置，那么调用将直接由 EAGAIN 错误返回。
mq_timedsend() 的行为与 mq_send() 很类似，只是消息队列满且 O_NONBLOCK 标志没有设置时，abs_timeout 指向的结构指定了一个阻塞的软上限时间。这个上限通过从 Epoch 1970-01-01 00:00:00 +0000 (UTC) 开始的绝对的秒和纳秒数指定超时，它的结构定义如下：
struct timespec { time_t tv_sec; /* 秒 */ long tv_nsec; /* 纳秒 */ };
如果消息队列满，并且调用时超时设置已经达到，mq_timedsend() 立刻返回。
返回值
成功时，mq_send() 和 mq_timedsend() 返回零；错误时，返回 -1，并把 errno 设置为合适的值。
错误 EAGAIN 队列已满，并且由 mqdes 消息队列描述符 O_NONBLOCK 标志设置。 EBADF mqdes 指定的描述符无效。 EINTR 这个调用被信号处理器中断，参看 signal(7)。 EINVAL 调用需要阻塞，但 abs_timeout 无效，要么因为 tv_sec 小于零，要么因为 tv_nsec小于零或大于 100 百万。 EMSGSIZE msg_len 大于消息队列的 mq_msgsize 属性。 ETIMEDOUT 在消息传输完成之前已超时。
需要 -lrt 来链接。
glibc 需要特性测试宏(参看 feature_test_macros(7))：
mq_timedreceive()：
如果队列是空的，默认情况下，mq_receive() 会阻塞到有消息准备好为止，或者被信号处理器中断为止。如果消息队列描述符的O_NONBLOCK 标志启用，则调用会以错误 EAGAIN 立即返回。
mq_timedreceive() 的行为与 mq_receive() 很相似，只不过当队列是空且 O_NONBLOCK 标志没有针对相应消息队列描述符启用时，调用会阻塞到 abs_timeout 时间点时返回。这个软上限是一个绝对的时刻值，它计算从 Epoch 1970-01-01 00:00:00 +0000 (UTC) 开始的秒数和纳秒数，这个结构的定义如下：
需要 -lrt 来链接。
消息队列通过 mq_open(3) 创建和打开，这个函数返回一个 消息队列描述符 (mqd_t)，它将在之后调用中被用于引用那个打开的消息队列。每个消息队列都通过形如 /somename 的名字来区分，这是一个包含起始斜杠在内的最大长度不超过 NAME_MAX(如 225)的以空字符结尾的字符串，在起始斜杠之后不允许再有斜杠。两个进程可能通过在使用 mq_open(3) 时传递相同的名字来打开相同的消息队列。
消息可以使用 mq_send(3) 和 mq_receive(3) 在一个队列里传入和传出。当一个进程不再使用队列时，可以通过 mq_close(3) 来关闭它，并且要是这个队列在将来也不会使用时，可以通过 mq_unlink(3) 来删除它。队列属性可以通过 mq_getattr(3) 和 mq_setattr(3) 来取得和更改(在一些情况下)。一个进程可以使用 mq_notify(3) 在一个空的队列时请求异步的卡片消息到达通知。
一个消息队列描述符引用一个 消息队列打开描述符 (参考 open(2))。在调用 fork(2) 之后，子进程继承了父亲消息队列描述符的复本，并且这些描述符引用与父亲中相应描述符相同消息队列打开描述符。在两个进程里相关描述符共享消息队列打开描述符相关的标志位(mq_flags)。
每个消息都有一个相关的 优先级，并且高优先级的消息总是首先传递给接收进程。消息优先级范围在 0(低优先级) 到sysconf(_SC_MQ_PRIO_MAX) - 1 (高优先级)。在 Linux 系统里，sysconf(_SC_MQ_PRIO_MAX) 返回 32768，但是 POSIX.1-2001 只要求实现提供优先级范围 0 到 31；一些实现只提供了这个范围。
一旦这个文件系统被挂载，系统里的消息队列就可以使用大家熟悉的命令(如 ls(1) 和 rm(1))来查看和维护了。
目录里的每一个文件都只包含相应队列信息一行内容：
消息队列通过 mq_open(3) 创建和打开，这个函数返回一个 消息队列描述符 (mqd_t)，它将在之后调用中被用于引用那个打开的消息队列。每个消息队列都通过形如 /somename 的名字来区分，这是一个包含起始斜杠在内的最大长度不超过 NAME_MAX(如 225)的以空字符结尾的字符串，在起始斜杠之后不允许再有斜杠。两个进程可能通过在使用 mq_open(3) 时传递相同的名字来打开相同的消息队列。
消息可以使用 mq_send(3) 和 mq_receive(3) 在一个队列里传入和传出。当一个进程不再使用队列时，可以通过 mq_close(3) 来关闭它，并且要是这个队列在将来也不会使用时，可以通过 mq_unlink(3) 来删除它。队列属性可以通过 mq_getattr(3) 和 mq_setattr(3) 来取得和更改(在一些情况下)。一个进程可以使用 mq_notify(3) 在一个空的队列时请求异步的卡片消息到达通知。
一个消息队列描述符引用一个 消息队列打开描述符 (参考 open(2))。在调用 fork(2) 之后，子进程继承了父亲消息队列描述符的复本，并且这些描述符引用与父亲中相应描述符相同消息队列打开描述符。在两个进程里相关描述符共享消息队列打开描述符相关的标志位(mq_flags)。
每个消息都有一个相关的 优先级，并且高优先级的消息总是首先传递给接收进程。消息优先级范围在 0(低优先级) 到sysconf(_SC_MQ_PRIO_MAX) - 1 (高优先级)。在 Linux 系统里，sysconf(_SC_MQ_PRIO_MAX) 返回 32768，但是 POSIX.1-2001 只要求实现提供优先级范围 0 到 31；一些实现只提供了这个范围。
一旦这个文件系统被挂载，系统里的消息队列就可以使用大家熟悉的命令(如 ls(1) 和 rm(1))来查看和维护了。
目录里的每一个文件都只包含相应队列信息一行内容：
$ cat /dev/mqueue/mymq QSIZE:129 NOTIFY:2 SIGNO:0 NOTIFY_PID:8260 这些域的含意如下： QSIZE 队列里所有消息的总字节数 NOTIFY_PID 如果这不是零，那么 进程号为 PID 进程已经使用 mq_notify(3) 来注册异步消息通知，并且剩余的域用来描述通知如何发出。 NOTIFY 通知方式：0 是 SIGEV_SIGNAL；1 是 SIGEV_NONE；以及 2 是 SIGEV_THREAD。 SIGNO 对于 SIGEV_SIGNAL 方式所使用信号数字。轮询消息队列描述符在 Linux 里，一个消息队列描述符是一个真实的文件描述符，冻僵可以使用 select(2)、poll(2) 或epoll(7) 来监视。这不具移植性。 遵循于POSIX.1-2001. 注意System V 消息队列(msgget(2)、msgsnd(2)、msgrcv(2) 等等)是一组老的用于进程交互消息的 API 。POSIX 消息队列提供了一组优于 System V 消息队列的接口设计；另一方面 POSIX 消息队列又不如 System V 消息队列受到的支持程度好(尤其是老的系统里)。目前(2.6.26) Linux 不支持在 POSIX 消息队列里应用访问控制列表(ACLs)。
====================================================
消息队列system v接口API
int msgget(key_t key, int msgflg);
描述
msgget() 系统调用返回一个与参数 key 相关联的消息队列标识符。如果这个 key是值 IPC_PRIVATE 或 key 不是 IPC_PRIVATE 而又不存在关联于给定key 的消息队列并且 IPC_CREAT 在 msgflg中指定，那么一个新的消息队列被创建。
如果 msgflg 同时指定了 IPC_CREAT 和 IPC_EXCL 并且一个关联key 的消息队列存在，则 msgget() 将失败并且设置 errno为EEXIST。(这与 open(2) 组合O_CREAT | O_EXCL 有相同效果。)
如果创建了消息，则参数 msgflg 有意义的最后几个位定义了消息队列的权限。这些权限位的格式与语义同open(2) 中的 mode参数相同。(执行权限没有使用。)
如果新消息队列被创建了，那么它关联的 msqid_ds 结构(参考 msgctl(2))按如下方式初始化：
msg_perm.cuid 和 msg_perm.uid 被设置用调用进程的有效用户ID。
msg_perm.cgid 和 msg_perm.gid 设置为调用进程的有效组 ID。
msg_perm.mode 最后有效的 9 个位使用 msgflg 最后有效的 9个位来设置。
msg_qnum、msg_lspid、msg_lrpid、msg_stime和 msg_rtime 都设置为 0。
msg_ctime 设置为当前时间。
msg_qbytes 设置为系统限制 MSGMNB。
如果一个消息队列已经存在并且权限认证通过，则会额外查看一下队列是不是被标志为释放。
返回值如果成功，返回值将是消息队列标识符(一个非负整数)，否则的话 -1 被返回并设置 errno 来指明错误。错误如果失败，errno 可能被设置为如下值：EACCES已经有一个关联于 key 的消息队列，但是调用进程没有对这个队列的访问权限，同时这个进程没有CAP_IPC_OWNER 特权。
EEXIST关联 key 的消息队列已经存在而 msgflg 却同时设置了 IPC_CREAT和 IPC_EXCL。
ENOENT不存在关联于 key 的消息队列可 msgflg 没有指定IPC_CREAT。
ENOMEM必需创建一个消息队列但系统没有足够的内存来建立相应的数据结构。
ENOSPC必需创建一个消息队列但是系统允许的最大消息队列个数(MSGMNI) 已经达到。遵循于SVr4, POSIX.1-2001。注意IPC_PRIVATE 不是一个标志域而一个 key_t 类型的值。如果使用这一个特殊值作为key，msgflg 除了最后 9 位以外的其它内容都会被系统调用忽略，并且新建一个(成功)消息。
下面是一些对 msgget() 有效果的系统限制：
MSGMNI系统范围内的消息队列最大数目：策略相关的(在 Linux 系统里，这个限制可能通过/proc/sys/kernel/msgmni 读取和悠。
int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);
ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp, int msgflg);
参数：
msqid：消息队列的识别码。
msgp：指向消息缓冲区的指针，此位置用来暂时存储发送和接收的消息，是一个用户可定义的通用结构，形态如下
struct msgbuf {
long mtype;
char mtext[1];
};
msgsz：消息的大小。
msgtyp：从消息队列内读取的消息形态。如果值为零，则表示消息队列中的所有消息都会被读取。
msgflg：用来指明核心程序在队列没有数据的情况下所应采取的行动。如果msgflg和常数IPC_NOWAIT合用，则在msgsnd()执行时若是消息队列已满，则msgsnd()将不会阻塞，而会立即返回-1，如果执行的是msgrcv()，则在消息队列呈空时，不做等待马上返回-1，并设定错误码为ENOMSG。当msgflg为0时，msgsnd()及msgrcv()在队列呈满或呈空的情形时，采取阻塞等待的处理模式。
返回说明：
成功执行时，msgsnd()返回0，msgrcv()返回拷贝到mtext数组的实际字节数。失败两者都返回-1，errno被设为以下的某个值
[对于msgsnd]
EACCES：调用进程在消息队列上没有写权能，同时没有CAP_IPC_OWNER权能
EAGAIN：由于消息队列的msg_qbytes的限制和msgflg中指定IPC_NOWAIT标志，消息不能被发送
EFAULT：msgp指针指向的内存空间不可访问
EIDRM：消息队列已被删除
EINTR：等待消息队列空间可用时被信号中断
EINVAL：参数无效
ENOMEM：系统内存不足，无法将msgp指向的消息拷贝进来
[对于msgrcv]
E2BIG：消息文本长度大于msgsz，并且msgflg中没有指定MSG_NOERROR
EACCES：调用进程没有读权能，同时没具有CAP_IPC_OWNER权能
EAGAIN：消息队列为空，并且msgflg中没有指定IPC_NOWAIT
EFAULT：msgp指向的空间不可访问
EIDRM：当进程睡眠等待接收消息时，消息已被删除
EINTR：当进程睡眠等待接收消息时，被信号中断
EINVAL：参数无效
ENOMSG：msgflg中指定了IPC_NOWAIT，同时所请求类型的消息不存在
int msgctl(int msqid, int cmd, struct msqid_ds *buf)
msgctl 系统调用对 msgqid 标识的消息队列执行 cmd 操作，系统定义了 3 种 cmd 操作： IPC_STAT , IPC_SET , IPC_RMID ，意义分别如下：
- IPC_STAT : 该命令用来获取消息队列对应的 msqid_ds 数据结构，并将其保存到 buf 指定的地址空间。
- IPC_SET : 该命令用来设置消息队列的属性，要设置的属性存储在 buf 中，可设置的属性包括： msg_perm.uid , msg_perm.gid , msg_perm.mode 以及 msg_qbytes .
- IPC_RMID : 从内核中删除 msqid 标识的消息队列。
