追加のサーバー データを使用しないハンドラーの実装とアクティブ化

ハンドラーのインスタンスを作成するには、追加のサーバー データを取得しない場合、サーバーは IStdMarshalInfo を実装する必要がありますが、IMarshal は実装しません。 IStdMarshalInfo には GetClassForHandler メソッドが 1 つあり、宛先プロセスで使用されるオブジェクト ハンドラーの CLSID を取得します。 COM は CoMarshalInterface を呼び出し、クライアント側でハンドラーをアクティブ化するときにこれを呼び出します。

次に、サーバー実装とハンドラー実装の両方で CoGetStdMarshalEx 関数を呼び出す必要があります。 この関数は、各側に標準マーシャラー (クライアント側ではプロキシ マネージャー、サーバー側ではスタブ マネージャーと呼ばれます) を作成します。

サーバーは CoGetStdMarshalEx を呼び出し、フラグ SMEXF_Standard Edition RVER を渡します。 これにより、サーバー側の標準マーシャラー (スタブ マネージャー) が作成されます。 サーバー側の構造を次の図に示します。

Diagram that shows the server-side structure.

サーバー側の構造

ハンドラーは CoGetStdMarshalEx を呼び出し、フラグ SMEXF_HANDLER を渡します。 これにより、クライアント側の標準マーシャラー (プロキシ マネージャー) が作成され、クライアント側のハンドラーと集約されます。 両方の有効期間は、ハンドラーが CoGetStdMarshalEx を呼び出すときにシステムが実装する制御 ID オブジェクト (IUnknown の実装) によって管理されます。 クライアント側の構造を次の図に示します。

DIagram that shows the client-side structure.

クライアント側の構造

上の図に示されているように、ハンドラーは実際にはプロキシ マネージャーと ID/制御不明の間に挟まれています。 これにより、システムはオブジェクトの存続期間全体を制御できるようになり、ハンドラーは公開されたインターフェイスを制御できるようになります。 ID マネージャーとプロキシ マネージャーの間の破線は、この 2 つが内部プライベート インターフェイスを通じて緊密な統合を共有していることを示しています。

COM がクライアントの CoUnmarshalInterface を呼び出すと、ハンドラー インスタンスが作成され、ID で集計されます。 ハンドラーは標準マーシャラーを作成します (CoGetStdMarshalEx の呼び出しを通じて、作成時に受信した制御不明を渡します)。 ハンドラーは IMarshal を実装しませんが、標準マーシャラーから IMarshal を返すだけです。 ハンドラーが IMarshal を実装している場合でも、アンマーシャル中に呼び出されることはありません。

2 つのスレッドが初めて同じオブジェクトを同時にアンマーシャリングする場合、2 つのハンドラーが一時的に作成される可能性があります。 その後、1 つのハンドラーがリリースされます。

軽量クライアント側ハンドラー