1

静的 C++ データが複数のプロセス間で共有されているように見える、COM DLL の実行中の予期しない動作を理解したいと思います。環境は少し複雑で、さまざまな COM スレッド モデルについての私の理解はやや不十分です。誰かが助けてくれることを願っています。

環境

  • 複数の C# Web サービスを実行する 64 ビット OS 上の IIS サーバー。各サービスは独自の 32 ビット アプリケーション プールにあるため、
    • プールには「32 ビット アプリケーションを有効にする」=True 設定があります。
  • 各 32 ビット C# サービスは、異なるインプロセス 32 ビット COM DLL を呼び出します (したがって、サービス A は COM DLL 1 を呼び出し、サービス C は COM DLL 2 を呼び出します。COM DLL は、Qt 4.8 ActiveQt を使用して C++ で記述されます。
  • COM DLL は、共有されている多数の 32 ビット C++ DLL に依存しています。つまり、COM DLL 1 と 2 の両方が Utilities.dll に依存しています。
  • 私が知る限り、COM DLL に ThreadingModel が設定されていないため、システムがメイン STA にフォールバックすると予想しています。
    • これが嫌われていることは承知していますが、現在それを変更するのに十分な知識がありません。
  • Utilities.dll には静的な C++ データが含まれています
  • COM DLL は「regsvr32」を使用して登録されており、「コンポーネント サービス」にリストされていないようですが、後者に関する私の知識は最小限です。

観測された問題は、Utilities.dll 内の静的データが異なる IIS プロセス間で共有されているように見え、望ましくない結果をもたらすことです。COM はメイン STA にあるため、スレッドセーフではないかのようにアクセスされ、各プロセスが DLL 静的データの独自のコピーを取得することを期待していましたが、そうではないようです。

プロセス間で静的データがどのように共有されるのか、誰か説明できますか?

どうすればこれを回避できますか? （コードをリファクタリングしてすべての静的データを削除することは別として、これは現在実際には実行可能ではありません）

4

1 に答える 1

1

COM オブジェクト間でデータが共有されている場合は、それらが同じプロセスでホストされていることを意味します。はい、プロセス間でデータを共有することは可能ですが、偶然ではありません。アプリ プールは異なるプロセスであるため、これらの COM オブジェクトはプロセス外でホストされている必要があり、アプリ プールに読み込まれるのは単なるスタブです。

Utilities.dll を制御できる場合 (そして、制御できるように思えます)、デバッグ情報を追加して、COM オブジェクトをホストしているプロセス ID を特定します。アプリ プール ID と一致しないことがわかると思いますが、その ID を使用して何が起こっているのかを調べることができます。

理想的には、適切に設計された COM オブジェクトがどこに存在するかは重要ではありません。それは、実装の詳細の一部であるはずです。共有データ構造を廃止することは可能ですか?

于 2013-03-13T18:09:03.020 に答える