ipcs 的“文件”在哪里以及为什么命名管道 (mkfifo) 未在 ipcs 中列出

Question 1

这里有几个问题：

ipcs 中列出的元素的文件在哪里？

这取决于。队列在虚拟文件系统中是可见的。来自 mq_overview(7) ：

   Mounting the message queue file system
       On  Linux,  message queues are created in a virtual file system.  (Other implementations may also provide such a feature, but
       the details are likely to differ.)  This file system can be mounted (by the superuser) using the following commands:

           # mkdir /dev/mqueue
           # mount -t mqueue none /dev/mqueue

共享内存（shm_overview(7)）

   Accessing shared memory objects via the file system
       On Linux, shared memory objects are created in a (tmpfs) virtual file system, normally mounted under /dev/shm.  Since  kernel
       2.6.19,  Linux supports the use of access control lists (ACLs) to control the permissions of objects in the virtual file sys-
       tem.

信号量（sem_overview(7)）

   Accessing named semaphores via the file system
       On Linux, named semaphores are created in a virtual file system, normally mounted under /dev/shm,  with  names  of  the  form
       sem.somename.  (This is the reason that semaphore names are limited to NAME_MAX-4 rather than NAME_MAX characters.)

       Since  Linux  2.6.19,  ACLs can be placed on files under this directory, to control object permissions on a per-user and per-
       group basis.

为什么创建的命名管道mkfifo没有在中列出ipcs？

我对此不太确定，所以我只给出我的意见，而不是答案。我的假设是，由于它们存在于实际文件系统中，就像套接字一样，因此它们的管理方式与内核管理共享内存段和消息队列的方式不同。

mkfifo 创建的命名管道与 ipcmk 创建的消息队列有何不同？

管道和消息队列之间的主要区别在于管道只是两个进程之间的通信通道。它在字节级别起作用。你可以按照你想要的方式读写，并且你必须设计通信协议。它们是严格的 FIFO：在另一个字节之前写入的字节始终会在另一端先被读取。消息队列处理的是消息，而不是字节。通常，它们是不太严格的 FIFO。这取决于实现，但它们可以支持消息之间的优先级机制。

在某种程度上，消息队列提供了更多功能，但如果您愿意，您可以使用消息队列实现 FIFO，反之亦然。

Answer