ヒープに割り当てられたオブジェクトをdllから渡したい。明らかに、メモリは正しく管理する必要があります。私が考案した次の狡猾なスキームに問題がある人はいますか?
unbounded_buffer<shared_ptr<T>> buf;
shared_ptrが含まれているオブジェクトの削除機能を隠していることを認識しているので、dllの境界を越えて単独で使用しても問題はありません。
ヒープに割り当てられたオブジェクトをdllから渡したい。明らかに、メモリは正しく管理する必要があります。私が考案した次の狡猾なスキームに問題がある人はいますか?
unbounded_buffer<shared_ptr<T>> buf;
shared_ptrが含まれているオブジェクトの削除機能を隠していることを認識しているので、dllの境界を越えて単独で使用しても問題はありません。
この問題に関してMSFTから受け取ったものは次のとおりです。
はい、CreateThreadを使用して手動で作成されたスレッドでメッセージブロック(unbounded_bufferなど)を使用できます。
メッセージは、その割り当てと削除が同じdllで行われる必要があるため、dllの境界を越えることはできません。トランスフォーマーなどの一部のメッセージブロックは、新しいメッセージを割り当てます。したがって、彼らも同じ問題に苦しんでいます。unbounded_buffer>は、上記の問題を解決しない場合を除いて、完全に使用できます。タイプテンプレート引数は、メッセージ(つまりメッセージ)のペイロードタイプを参照します。封筒の種類ではありません。
定常状態では、データフローネットワークのスループットは非常に良好です。パフォーマンスの低下の主な原因は、ネットワークのセットアップ中のメッセージブロックのリンクとリンク解除です。Visual Studio 2010では、sendやasendなどのメッセージ開始コマンドがこのパフォーマンスの低下に悩まされていました。この問題は、VisualStudioの次のリリースで対処されています。修正をVS2010にバックポートする予定はありません。潜在的な回避策は、常にデータフローネットワークに接続されている単純なISourceメッセージブロックを実装することです。このブロックを使用して、ネットワークへのメッセージを開始します(agents.hの_OriginatorはISourceブロックの例です)。