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