Linuxではメッセージキューは廃止されますか？
私は最近Linuxでメッセージキュー（システムVですが、POSIXも大丈夫です）で遊んでいて、私のアプリケーションには完璧に見えますが、The Art of Unix Programmingを読んだ後、本当に良い選択かどうかわかりません。
http://www.faqs.org/docs/artu/ch07s02.html#id2922148
System V IPCの上部のメッセージパッシング層は、ほとんど使用されなくなりました。共有メモリとセマフォで構成される下部層は、必要な状況では依然として重要なアプリケーションを持っていますこれらのSystem V共有メモリ機能はPOSIX共有メモリAPIに進化し、Linux、BSD、MacOS X、Windowsでサポートされていますが、クラシックMacOSではサポートされていません。
http://www.faqs.org/docs/artu/ch07s03.html#id2923376
System V IPC機能はLinuxおよびその他の最新のUnixに存在します。しかし、それらはレガシー機能であるため、あまり頻繁に実行されません。Linuxバージョンにはまだバグがあることが知られています。 2003年半ば。誰もそれらを修正するのに十分な気がしないようです。
System Vのメッセージキューは、最新のLinuxバージョンでもまだバグがありますか？作者がPOSIXメッセージキューは大丈夫だと言っているのかどうかわかりませんか？
ソケットはほとんどの場合に優先されるIPC（？）のようですが、ソケットなどを使用してメッセージキューを実装するのが非常に簡単かどうかはわかりません。 ？
組み込みLinuxを使用することが適切かどうかわかりませんか？
個人的には、メッセージキューが非常に好きで、おそらくUnixの世界で最も活用されていないIPC。高速で使いやすい。
いくつかの考え：
これのいくつかは単なるファッションです。古いものが再び新しくなります。メッセージキューにピカピカのdo-dadを追加すると、来年の最新でホットなものになるかもしれません。 GoogleのChromeを見てください。タブにスレッドではなく別のプロセスを使用しています。突然、1つのタブがロックしてもブラウザ全体が停止しないことに人々は興奮しています。
共有メモリには、He-manハローのようなものがあります。マシンから最後のサイクルを絞り出さず、MQの効率がわずかに低い場合、あなたは「本当の」プログラマーではありません。ほとんどのアプリではないにしても、多くの人にとって、それはまったくナンセンスですが、時にはそれが定着すると、考え方を壊すのは難しいです。
MQは、無制限のデータを持つアプリケーションには実際には適切ではありません。パイプやソケットなどのストリーム指向のメカニズムは、そのために使用する方が簡単です。
System Vの亜種は、本当に好意的ではありません。一般的なルールとして、可能であればIPCのPOSIXバージョンを使用します。
はい、メッセージキューは一部のアプリケーションに適していると思います。 POSIXメッセージキューはより良いインターフェイスを提供します。特に、IDではなく名前をキューに付けることができます。これは障害診断に非常に役立ちます（どちらがどちらであるかを簡単に確認できます）。
Linuxでは、posixメッセージキューをファイルシステムとしてマウントし、「ls」で表示し、「rm」で削除することもできます（System Vは、不格好な「ipcs」および「ipcrm」コマンドに依存します）
POSIXメッセージキューを実際に使用したことがないのは、ネットワーク上でメッセージを配信するオプションを常に開いたままにするためです。それを念頭に置いて、 zeromq または [〜＃〜] amqp [〜＃〜] を実装するような、より堅牢なメッセージ受け渡しインターフェースを検討することができます。
0mqの優れた点の1つは、マルチスレッドアプリで同じプロセススペースから使用する場合、非常に高速なロックレスゼロコピーメカニズムを使用することです。それでも、同じインターフェースを使用して、ネットワーク経由でメッセージを渡すこともできます。
POSIXメッセージキューの最大の欠点：
- POSIXメッセージキューは、
select()との互換性を保つために要件にしません（Linuxではselect()で動作しますが、Qnxシステムでは動作しません） - 驚きがあります。
Unix Datagramソケットは、POSIXメッセージキューと同じタスクを実行します。また、Unix Datagramソケットはソケットレイヤーで動作します。 select()/poll()またはその他のIO-waitメソッドで使用できます。 select()/poll()を使用すると、イベントベースのシステムを設計するときに利点があります。そのようにしてビジーループを回避することができます。
メッセージキューには驚きがあります。 mq_notify()について考えてください。 receive-eventを取得するために使用されます。メッセージキューについて何か通知できるようです。しかし、実際には何も通知するのではなく、通知に登録しています。
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がそれに適しています。
しかし、it（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ソケットを常に好みます。