3

Linux用のプラグインアーキテクチャを書きたいです。私はそれを行う方法を研究しようとしましたが、実際には、必要なものよりも複雑なプラグインアーキテクチャの情報に遭遇し続けています。非常に基本的な実装のみが必要です。

私が行っていることを説明するために、さまざまなソースからの入力を受け入れて処理するプログラムがあります。同じプログラムの複数のインスタンスが実行され、各インスタンスが異なる入力ソースを受け入れる可能性があります。ある程度のエラーチェックと訂正を行いたいのですが、そのようなエラーチェックのロジックは入力ソースによって異なります。そのため、プログラムで読み込んでいる特定のソースのプラグインを開き(プラグイン名は構成ファイルにあると思われます)、ライブラリが提供するエラーチェックメソッドを実行する必要があります。これは、プラグインについて私が見るほとんどのアーキテクチャや情報よりも基本的です。

  • クロスプラットフォームではありません。x86 linuxプラットフォームを使用することはわかっており、必要に応じて正確なコンパイラーを定義することもできます。
  • 「プラグイン」は非常に基本的なものであり、各プラグインによって提供される単一のメソッドと同じくらい小さい場合があります。

しかし、私が持っていなければならないことが2つあります

1)高速でなければなりません。ストリーミングデータを大量に読み込んでいるので、すばやく処理する必要があります。私はまさにこの理由でスクリプトエージェントの使用を取り消しました。すべての入力に対してスクリプトロジックを変換するオーバーヘッドが非常に大きくなるのではないかと心配していました。

2)プログラムを停止せずに、既存の.SOの更新を検出し、新しいバージョンをロードできる必要があります。

私はまだ一般的にC++に少し慣れていないので、複雑すぎるものを開発しようとすることに少し不安を感じています。私は、私にとって最も簡単で実行可能な解決策が何であるかを判断しようとしています。

Boost.Extensionを検討しましたが、実際には必要なものに対してやり過ぎかもしれません。私のユースケースは非常に単純であるため、Boostフレームワークを使用するのではなく、手動で.SOを定義する方がよいかどうかを判断しようとしています。私が働いている場所でBoostを使用することには、いくつかの小さな頭痛の種もあります。それは可能ですが、許可を得るためにいくつかのフープを飛び越えなければなりません。

したがって、1)プラグインアーキテクチャが本当にここで試すべきものであるかどうかを誰かに教えてもらえますか(より簡単な解決策はありますか?)2)Boost.Extensionsが最善のアプローチであると考えている場合3)プラットフォーム固有のプラグインアーキテクチャを作成します(プラットフォームに依存しないことについて多くの話を見てきましたが、それほど複雑なことをする必要はありません)。4)実行中に新しいバージョンのライブラリを確実にロードするための最良の方法は何ですか?先に述べた高速処理の必要性から、入力を受け入れるたびにifステートメントを回避する方法が望ましい。

4

1 に答える 1

6

1)はい。あなたの場合、これは簡単な解決策です。Linuxには伝統的に単純なAPIがあり、共有ライブラリの作成/使用は通常簡単です(いくつかの注意点があります。以下を参照してください)。

2)Linuxをターゲットにしているため、プラットフォームに依存しない抽象化は必要ありません。プラットフォームに依存しない共有ライブラリ管理は、厄介な詳細でいっぱいです。ここでは、これについては気にしません。Boost Extensionsは、Linuxのみのソリューションよりも単純ではない場合があります。

3)C関数を使用しdlopenます(つまり、事前にマングリングについて学び、名前を付けます)。C++とdlsym/dlopen(このような)を扱うチュートリアルはたくさんあります。基本的に、インターフェイスは単純であるほど優れています(C関数がいくつかあり、クラスがないことが最適です)。dlsymextern "C"

4)inotifyファイルシステムイベント通知のLinux標準であるをご覧ください。ロードしたライブラリごとにウォッチを追加すると、ハンドラーから変更が通知されます。ハンドラーは、必要に応じてライブラリをリロードするために、メインループにフラグを設定する必要があります。

于 2012-07-11T16:57:20.380 に答える