1

別のアプリがそれを通知したときに呼び出される「コールバック」関数をアプリが登録できる、ユーザーモードの同期メカニズムに精通している人がいるのだろうか...コールバックが任意の スレッドにあることを気にしない.

並行して多くの「ワーカー」プロセスがあり、すべてのプロセスが内部更新を行う必要がある変更を通知したいとします (ペイロード データは必要ありません)。

これに対する当面のアプローチは、それぞれに別のスレッドを作成し、グローバル イベントを待機してその直後にコールバック関数を呼び出す無限ループを作成することでした。これを通知するには、1 つのプロセスがこのグローバル イベントを通知するだけで済みます。

問題は、このプロジェクトに多くの並列プロセスがあることです。これを実装するためだけにシステムに thread*nProcesses を追加したくありません。たとえそれらがほとんど一時停止していてもです。

これに対して私が見つけた現在の「回避策」は、自分の「ダミー」レジストリキーを保持することであり、すべてのプロセスは「登録通知コールバックを登録」します.1つのアプリが他のアプリに通知したい場合、このキーへの書き込みをトリガーするだけです. ..そしてウィンドウは、この通知に登録されたすべてのプロセスをコールバックします。

他のアイデアはありますか？

4

2 に答える 2

1

レジストリを汚染しないより良い解決策は、共有パイプを使用することです。すべてのワーカーは名前付きパイプ サーバーに接続し、非同期読み取りを実行できます。サーバーがワーカーをキックしたいときは、バイトを書き込むだけです。これにより、ワーカーの完了ルーチンがトリガーされます。基本的な例

それでも、この通知には、他のほとんどの Windows 通知と同じ欠点があります。すべてのワーカー スレッドがワーカー コードを実行している場合、通知を受け取ることができるスレッドはありません。また、その目的のために特別なスレッドを作成していません。その周りの唯一の解決策は ですがCreateRemoteThread、それは非常に大きなハンマーです。

于 2012-09-27T14:07:47.377 に答える
0

皆様、有益なアイデアをありがとうございます

最終的に、まさにそれを行うと思われるRegisterWaitForSingleObjectに偶然出くわしました。

このコールバック メカニズムはほとんどの Win32API と同じコールバック メカニズムに依存していると想定しているため、特定の時間に十分な空きワーカー スレッドがないという @MSalters のコメントをまだ考慮しています。

于 2012-10-11T13:16:41.300 に答える