ホスト アプリケーションのプラグインとして使用される一連の DLL を開発および保守しています。ホスト アプリケーションには、プラグインが実装するプラグイン API があります。ホスト アプリケーションは別の会社によって開発されており、プラグインの使用方法を制御することはできません。ホスト アプリケーションは、いつでも任意の順序で任意のプラグインをロード/アンロードする可能性があります。プラグインは任意のスレッドで実行でき、異なるスレッドから呼び出すこともできます。
これらのプラグイン プラグインが共通のリソースを共有する方法が必要です。このリソースは、ロードされる最初のプラグインによって初期化され、アンロードされる最後のプラグインによって初期化されないようにする必要があります。最初と最後は異なるプラグインかもしれません。スレッドの安全性は重要な問題です。
これは、現在ロードされているすべてのプラグイン間で共有されるシングルトンと考えることができます。
考えられる解決策は、すべてのプラグインが、ロード時にシングルトンを初期化し、アンロード時に破棄する共通の DLL を共有することです。ただし、ユーザーのマシンへの展開を容易にするために、可能であればプラグインを自己完結型にしたいと考えています。
ホスト アプリケーションはクロス プラットフォームであるため、ソリューションはクロス プラットフォームであり、Windows、Mac OS、および Linux で同じように動作する必要があります (可能な場合)。その趣旨で、boost を検討しましたが、boost プロセス間コードのクラスとオプションの数に圧倒されました。
コード化された完全な解決策を求めるのではなく、この問題に取り組む最善の方法についてのアドバイスを求めます。
詳細と質問への回答:
ここでの問題は、ホスト アプリケーションからの助けを期待できないことです。そのため、それが何であるかは問題ではありません。実際にはプラグインを使用するアプリケーションがいくつかあるため、単一のアプリケーションの特定の機能に依存することはできません。ホスト アプリケーションは通常のデスクトップ アプリケーションであると言えます。たとえば、Windows ではプレーンな古い .exe、Mac OS では .app です。iOS または Android アプリはありません。
プラグイン インターフェイスは、ホストが呼び出すことができる関数のセットです。API は 1 つの方法です。ホストはプラグインを呼び出すことができますが、プラグインはホストを呼び出すことはできません。各プラグインには、ロード時にホストが呼び出す必要がある初期化関数と、ホストが DLL をアンロードする前に 1 回呼び出す必要がある初期化関数があります。
プラグインは C++ で実装されていますが、C++11 では実装されていません。コンパイラは、Windows では VisualStudio 2005、Mac では gcc 4.2.1 を使用した Xcode 3.2 です。とはいえ、特定のコードではなく、問題にアプローチするための一般的な設計を探していることをもう一度強調したいと思います。
助けてくれてありがとう！