1

組み込み Linux プラットフォームで実行するアプリケーション (グラフィック部分に Qt を組み合わせた C++) に取り組んでいます。アプリケーション自体の安定性、効率、およびセキュリティを向上させるために、アプリケーションを異なる「コア」に分割し、それぞれがアプリケーションの異なる部分を処理する方法を知る必要があります。

私の疑問は次のとおりです。機能をスレッドに分割するか、異なるプロセスをフォークする方が便利ですか?

アプリケーションの機能的なビューを提供しましょう: それぞれ異なるユーザー インターフェイスがあり、ユーザーは多かれ少なかれ同じことを行うことができます (データの一貫性については気にしないでください。この問題は既に解決しています)。これらの各インターフェースは、スタンドアロンとして機能する必要があります (同じシステムの異なる端末のように)。アプリケーションデータの更新やその他の適切な処理を行う同じ「コア」からすべてのメッセージを送受信する必要があります。

内部の「コア」とユーザー インターフェイスの分割を実装する最良の方法は何ですか?

確かに私はいくつかの知識を欠いていますが、これまでのところ私は2つの選択肢を思いつきました.この場合、父と子を通信させることはできますか (子は新しいプロセスであることを念頭に置いてください)?) 2 - コアと UI ごとに異なるスレッドを作成します。

この部門が必要なのは、アプリケーションが可能な限り安定しており、クラッシュした場合に UI を再起動できる必要があるためです。また、アプリケーション全体で使用可能なメモリとリソースが無限にあるわけではないことにも注意してください。

よろしくお願いします。

4

2 に答える 2

2

組み込みシステムで別のプロセス ルートを使用することが適切な選択である理由はいくつかあります。

  • コンポーネントの分離: コンポーネントを個別のプロセスとして実行することは、究極の分離です。プロジェクトが非常に大きくなる場合に役立つことが多い

  • セキュリティと権限の管理: 組み込みシステムでは、デバイスを制御するために昇格された権限が必要なコンポーネントもあれば、可能な限り少ない権限で実行したい潜在的なセキュリティ上の危険 (ネットワークに面したコンポーネントなど) もある可能性が非常に高くなります。その他の可能性のあるシナリオは、リアルタイムのスレッド化が必要なコンポーネントやmmap()、大量のシステム メモリを使用できるコンポーネントです。いずれかの割り当てが過剰になると、システムがロックされて回復できなくなります。

  • 信頼できる: システムの一部が失敗した場合、残りの部分が実行されたままになっている可能性があります。

このような配置を構築することは、ここで他の人が示唆しているよりも実際には簡単です.Qtはdbusを非常によくサポートしています.dbusはIPCを適切に処理し、システム管理機能のためにLinuxデスクトップで広く使用されています.

あなたが説明するシナリオに関しては、アプリケーションの「コア」をデーモン化し、UI コンポーネントから dbus を介したクライアント接続を許可することができます。

于 2012-10-31T23:12:21.907 に答える
0

別のスレッドで UI を実行しても、安定性が向上するわけではありません。別のスレッドがエンジンのヒープを破壊する可能性があり、スレッドを終了しても、それが持っているリソースはリサイクルされません。

エンジンと UI の間に非常に強力な抽象化の壁を設けることで、安定性を少し向上させることができます。したがって、これは完全に無駄ではありません。

複数のプロセスをジャンプするには、多くのフープが必要です。IPC (プロセス間通信) の方法が必要です。

IPC と、程度は低いですが抽象化の壁によって、プログラムのオーバーヘッドが増える可能性があることに注意してください。

重要な質問は、「UI とエンジンの間でどのくらいのデータを渡す必要があるか」です。-- 十分なデータが少ない場合 (UI からエンジンへの「タスクの開始」、エンジンから UI への「このタスクは 50% 完了」など)、IPC は面倒ではありません。画像をリアルタイムで全画面表示するインタラクティブなペイント アプリケーションの場合、IPC は煩わしく実用的ではありません。

ここで、Qt と IPC を Google で簡単に検索すると、組み込み Linux 用の Qt 拡張機能があり、Qt シグナルとスロットがプロセス間でメッセージを渡すことができるようになることがわかりました: Qt COMmunications Protocol (QCOP)。このようなフレームワークで私が抱えていた問題の 1 つは、比較的単純なプロトコルと比較して、通信パイプの反対側の安定性を損なう可能性があるクライアントとサーバーの状態の間の絡み合いに簡単につながる可能性があることです。

于 2012-10-31T14:49:00.100 に答える