메시지 대기열은 Linux에서 더 이상 사용되지 않습니까?

메시지 대기열은 Linux에서 더 이상 사용되지 않습니까?

---

최근에 Linux에서 메시지 큐 (System V,하지만 POSIX도 괜찮을 것임)를 가지고 놀았는데, 내 애플리케이션에 완벽 해 보이지만 The Art of Unix Programming을 읽은 후에 정말 좋은 선택인지 확신 할 수 없습니다. .

http://www.faqs.org/docs/artu/ch07s02.html#id2922148

System V IPC의 상위 메시지 전달 계층은 대부분 사용이 중단되었습니다. 공유 메모리와 세마포로 구성된 하위 계층은 동일한 시스템에서 실행되는 프로세스간에 상호 배제 잠금 및 일부 글로벌 데이터 공유를 수행해야하는 상황에서 여전히 중요한 응용 프로그램을 가지고 있습니다. 이러한 System V 공유 메모리 기능은 Linux, BSD, MacOS X 및 Windows에서 지원되지만 클래식 MacOS에서는 지원되지 않는 POSIX 공유 메모리 API로 발전했습니다.

http://www.faqs.org/docs/artu/ch07s03.html#id2923376

System V IPC 기능은 Linux 및 기타 최신 Unix에 있습니다. 그러나 레거시 기능이므로 자주 사용되지 않습니다. Linux 버전은 2003 년 중반 현재 버그가있는 것으로 알려져 있습니다. 아무도 그것들을 고칠만큼 신경 쓰지 않는 것 같습니다.

최신 Linux 버전에서 System V 메시지 대기열이 여전히 버그가 있습니까? 작성자가 POSIX 메시지 대기열이 정상이어야 함을 의미하는지 확실하지 않습니까?

소켓은 거의 모든 것 (?)에 대해 선호되는 IPC 인 것 같지만 소켓이나 다른 것으로 메시지 큐를 구현하는 것이 얼마나 간단한 지 알 수 없습니다. 아니면 너무 복잡하게 생각하고 있습니까?

임베디드 Linux로 작업하는 것이 관련성이 있는지 모르겠습니다.

---

개인적으로 저는 메시지 큐를 아주 좋아하며 유닉스 세계에서 가장 잘 활용되지 않는 IPC라고 생각합니다. 빠르고 사용하기 쉽습니다.

몇 가지 생각 :

• 이 중 일부는 패션입니다. 오래된 것이 다시 새롭습니다. 메시지 대기열에 빛나는 do-dad를 추가하면 내년에 가장 새롭고 인기있는 것이 될 수 있습니다. 탭에 대한 스레드 대신 별도의 프로세스를 사용하여 Google의 Chrome을 살펴보세요. 갑자기 사람들은 하나의 탭이 잠길 때 전체 브라우저가 다운되지 않는다는 사실에 감격합니다.

• 공유 메모리에는 He-man의 후광이 있습니다. 머신에서 마지막주기를 짜 내지 않고 MQ가 약간 덜 효율적이라면 당신은 "진짜"프로그래머가 아닙니다. 대부분의 앱은 아니지만 많은 사람들에게 그것은 완전히 말도 안되는 일이지만 때로는 일단 자리를 잡으면 사고 방식을 깨는 것이 어렵습니다.

• MQ는 실제로 제한되지 않은 데이터가있는 응용 프로그램에 적합하지 않습니다. 파이프 또는 소켓과 같은 스트림 지향 메커니즘은 사용하기가 더 쉽습니다.

• System V 변종은 실제로 선호되지 않았습니다. 일반적으로 가능한 경우 POSIX 버전의 IPC를 사용하십시오.

---

예, 일부 응용 프로그램에는 메시지 대기열이 적합하다고 생각합니다. POSIX 메시지 큐는 더 좋은 인터페이스를 제공합니다. 특히 ID가 아닌 큐 이름을 제공 할 수 있습니다. 이는 오류 진단에 매우 유용합니다 (어느 쪽인지 쉽게 알 수 있음).

Linux에서는 posix 메시지 큐를 파일 시스템으로 마운트하고 "ls"로 확인하고 "rm"으로 삭제할 수 있습니다. 이는 매우 편리합니다 (시스템 V는 "ipcs"및 "ipcrm"명령에 따라 다릅니다).

---

나는 항상 네트워크를 통해 내 메시지를 배포하는 옵션을 열어두고 싶기 때문에 실제로 POSIX 메시지 대기열을 사용하지 않았습니다. 이를 염두에두고 zeromq 또는 AMQP 를 구현하는 것과 같은보다 강력한 메시지 전달 인터페이스를 살펴볼 수 있습니다 .

0mq의 좋은 점 중 하나는 다중 스레드 앱의 동일한 프로세스 공간에서 사용될 때 매우 빠른 잠금없는 제로 복사 메커니즘을 사용한다는 것입니다. 그래도 동일한 인터페이스를 사용하여 네트워크를 통해 메시지를 전달할 수도 있습니다.

---

POSIX 메시지 큐의 가장 큰 단점 :

• POSIX 메시지 대기열은 . ( Linux에서는 작동 하지만 Qnx 시스템에서는 작동 하지 않음) 와 호환되도록 요구 하지 않습니다 select().select()
• 놀라움이 있습니다.

Unix Datagram 소켓은 POSIX 메시지 대기열과 동일한 작업을 수행합니다. 그리고 Unix Datagram 소켓은 소켓 계층에서 작동합니다. select()/ poll()또는 다른 IO 대기 방법 과 함께 사용할 수 있습니다. select()/ poll()를 사용하면 이벤트 기반 시스템을 설계 할 때 유리합니다. 이런 식으로 바쁜 루프를 피할 수 있습니다.

메시지 대기열에 놀라움이 있습니다. 에 대해 생각하십시오 mq_notify(). 수신 이벤트를 얻는 데 사용됩니다. 메시지 대기열에 대해 알릴 수있는 것 같습니다. 그러나 실제로 알리는 대신 알림을 등록합니다.

더 놀라운 점 mq_notify()은 매번 호출해야한다는 것입니다. mq_receive()이로 인해 경쟁 조건이 발생할 수 있습니다 ( 및 호출 mq_send()사이에 다른 프로세스 / 스레드 호출시 ).mq_receive()mq_notify()

그리고 그것은 mq_open, mq_send(), mq_receive() and mq_close()중복되고 어떤 경우에는 소켓 open(),send(),recv() and close()메소드 사양 과 일치하지 않는 자체 정의를 가진 전체 세트를 가지고 있습니다.

동기화를 위해 메시지 큐를 사용해야한다고 생각하지 않습니다. eventfd그에 signalfd적합합니다.

그러나 그것 (POSIX 메시지 큐)은 일부 실시간 지원이 있습니다. 우선 기능이 있습니다.

Messages are placed on the queue in decreasing order of priority, with newer messages of the same priority being placed after older messages with the same priority.

그러나이 우선 순위는 대역 외 데이터로 소켓에도 사용할 수 있습니다!

마지막으로, POSIX 메시지 큐는 레거시 API입니다. 실시간 기능이 필요하지 않은 한 항상 POSIX 메시지 대기열 대신 Unix Datagram 소켓을 선호합니다.

참고 URL : https://stackoverflow.com/questions/967335/are-message-queues-obsolete-in-linux