データベースまたはファイルを単純なデータ永続化レイヤーとして操作することは理解しやすいです。しかし、それらを通信チャネルとして使用して、実行中のプロセスから別のプロセスにデータを転送したり、コマンドやリクエストを送信したりする方法もあります。特に、このチャネルが共有メモリなどの通常の Unix ソケットよりも高速な場合です。
しかし、これをどのように効率的に使用しますか？つまり、プロセスは共有メモリの変更に対してイベントを取得しません。プロセスは常にそれをポーリングする必要がありますよね? しかし、すべてのプロセスが常に共有メモリをポーリングしているとしたら、リソースを大量に消費するのではないでしょうか? 他にどのような選択肢がありますか？
Unix または Linux システムで IPC を使用して変更の通知を受け取るには、ポーリングに頼らずに別の手法を考えることができます。
最初のブロッキング読み取り
ファイル記述子 (ファイル、Unix ソケット、パイプまたは名前付きパイプ、IPC キューなど) を使用できます。コンシューマーはこのファイルをブロックする方法で読み取ります (おそらくタイムアウトが推奨されます)。プロデューサは、共有メモリを更新すると、このファイル記述子に何かを書き込みます。したがって、これが発生すると、消費者は読み取りから目覚め、共有メモリを読み取りに行きます。コンシューマーはスリープ状態になるため、待機中にリソース (CPU など) を消費しません。
selectコンシューマーが同時に複数のファイル記述子を待機するように使用することもできます。
セカンドシグナル
コンシューマーは、プロデューサーから送信されたシグナルによって起動されます。プロデューサは、共有メモリを更新すると、シグナル (たとえば SIGUSR1) をコンシューマに送信します。コンシューマーは以前にシグナルをサブスクライブしており、リクエストを処理できます。イベントはいつでもトリガーされる可能性があるため、処理が少し複雑になり、コンシューマーの設計が難しくなります。
ファイルとデータベースはデータを格納するために設計されており、IPC でそれらを使用することはヘルパーとしてのみ可能であり、他のメカニズム (ミューテックス、イベント、セマフォなど) はデータへのアクセスを同期し、変更について通知するために使用されます。これらのメカニズムは「リッスン」されており、そのようなシグナルを待機するためにリソースを消費することはありません。一方、変更をキャッチしようとするファイルの読み取り (これは、メモリ マップ ファイルまたは共有メモリに適用されます) は、リソースを浪費し、読み取りアクセスと書き込みアクセスを同期しないと問題を引き起こす可能性があります (これにより、mutex とイベントなど）