問題タブ [message-loop]

最近、Win32 でモードレス ダイアログを使用したい状況に遭遇しました。

Win32: ツールバー ダイアログがフォーカスされず、メイン ウィンドウの処理が遅くなる!?

そして、これが私のメッセージループであることがわかりました：

実際、このメッセージ ループは、モーダル ダイアログが独自のメッセージ ループを処理するため、モーダル ダイアログで完全に正常に動作するため、モードレス ダイアログがない限り正常に動作します。hWndのインスタンスを置き換えたとき、モードレス ダイアログは問題なく動作しましたNULL。違いはわかりませんが、特定のウィンドウではなくメッセージが表示されるようです。

このメッセージ ループが正しく動作しない原因を誰か説明できますか?

これとして：

完璧に動作します！

Windows プログラミングでは、MessageLoop を使用する必要がありますか?

どのプログラムにも messageLoop があることがわかりますが、このコードでは autor は messageloop を使用していません

コードスニペット ：

C＃で非同期的に低レベルのメッセージを処理/フィルタリングするための2番目のメッセージループを作成しようとしています。これは、非表示のフォームを作成し、そのHandleプロパティを公開してフックし、別のスレッドで2番目のメッセージループを実行することで機能します。現時点では結果には非常に満足していますが、2番目のループを適切に終了することができません。唯一の回避策は、IsBackgroundプロパティをtrueに設定することでした。そのため、2番目のスレッドは、メインアプリケーションの終了時に（保留中のメッセージをすべて処理せずに）単純に終了します。

問題は、2番目のApplication.Run（）が戻るように、そのメッセージループを適切に終了する方法です。別のApplicationContextを作成し、さまざまなイベント（Application.ApplicationExit、Application.ThreadExit、ApplicationContext.ThreadExit）を制御するさまざまなアプローチを試しましたが、デバッグできない競合状態ですべて失敗しました。

ヒントはありますか？ありがとう

これはコードです：

メインのFormコンストラクターで次のように使用します。

編集：私の答えの完全な解決策。

以下のコードがある場合、ウィンドウが閉じられたことを検出して終了するにはどうすればよいですか？r値を取得することはないようです。現在のウィンドウだけでなく、スレッド全体のメッセージを処理する必要があります。-1 0

ゲームエンジンをmacに移植しようとしているときに、1つの基本的な（しかし大きな）問題に遭遇しました。Windowsでは、私のメインコードは次のようになります（非常に単純化されています）。

これはMacの方法ではないことをすでに読みました。Macの方法は、新しいフレームをレンダリングするために、画面のv-syncなどのある種のイベントをチェックすることです。しかし、ご覧のとおり、レンダリングだけでなく、他のスレッドにも機能させたいと思っています。一部のスレッドは、1/60秒ごとよりも速く呼び出す必要があります。（ちなみに、私のスレッドインフラストラクチャは次のとおりです。スレッドはイベントを同期キューに入れ、メインスレッドはプロセスイベントを呼び出します。これはメインスレッド内の同期キュー内のアイテムを処理します。これはネットワーク関連、画像の読み込み/処理、パーリンノイズに使用されます。世代など...など...）

同様の方法でこれを実行できるようにしたいと思いますが、これに関する情報はほとんどありません。レンダリングをv-syncイベントに配置してもかまいません（これはWindowsにも実装します）が、残りのコードの応答性をもう少し高めたいと思います。

このように見てください：GPUが処理を実行している間に残りを処理できるようにしたいと思います。v-syncが処理を開始するのを待ってから、すでに処理されているはずの処理を開始するのを待ちたくありません。 GPUにデータを送信します。私の言いたいことが分かりますか？

これをまったく別の視点から見る必要がある場合は、教えてください。

このために本/ガイド/チュートリアル/何かを読む必要がある場合は、何を読むべきか教えてください！

私はココア開発者ではなく、object-cプログラマーでもありません。また、ゲームエンジンは完全にC ++ですが、ウィンドウを表示し、そのウィンドウ内に描画したものを表示するのに十分なxcodeの使い方を知っています。私はそれを正しくする方法がわからないので、それは私のウィンドウズバージョンのように更新されません。

更新：垂直リトレースで同期したい場合でも、何らかのループが必要だとさえ信じています。MacOSXドキュメントのOpenGLプログラミングは、これがSwapIntervalを設定することによって行われることを示しています。したがって、正しく理解していれば、Macでリアルタイムにレンダリングするときは、swapInterval設定を使用して電力使用量を減らすために、常に何らかのループが必要になります。これは本当ですか？

ウィンドウなしで（つまり、コンソールアプリケーションから）Windows Raw Input APIを使用することは可能ですか？

RegisterRawInputDevicesを使用してみましたが、メッセージループがGetMessageからイベントを取得していないようであるため、「ハング」します。

グローバル ホットキーを登録するための C# API を作成する必要があります。WM_HOTKEY メッセージを受信するには、 を使用し、 を使用しSystem.Windows.Forms.NativeWindowて独自のメッセージ ループを実行しますSystem.Windows.Forms.Application.Run(ApplicationContext)。ユーザーがホットキーを登録したい場合、RegisterHotkey()でメッセージ ループを停止し、 (P/Invoke) 関数でホットキーを登録して、メッセージ ループを再開System.Windows.Forms.ApplicationContext.ExitThread()するというメソッドを実行する必要があります。ウィンドウを作成したのと同じスレッド内で呼び出す必要があり、メッセージ ループを実行する同じスレッド内で再度インスタンス化する必要があるRegisterHotKey()ため、これが必要です。RegisterHotKey()

問題は、ユーザーがRegisterHotkey()メッセージ ループを実行しているスレッドを開始した直後にメソッドを呼び出すと、そのApplicationContext.ExitThread()前に呼び出されるApplication.Run(ApplicationContext)ため、アプリケーションが無期限にブロックされることです。メッセージループが開始されるのを待つためのアプローチを知っている人はいますか?

前もって感謝します！

私の AS3 クライアント プログラムは、大量のメッセージを送信するときに、送信されたすべてのデータを受信しません。すべてのメッセージが正しく受信および送信されるため、この問題を引き起こしているのは私のサーバーではないことはわかっています。私の as3 クライアントは、送信されたすべてのデータを受信しません。

どなたか解決策をご存知ですか？

私の主な目標は、 USBHIDイベントを処理できるP/Invoke呼び出しだけで適切なメッセージループを実装することです。間違いなく、その機能は、 Windowsフォームでうまく機能する次のコードと同じである必要があります。このNativeWindowの子孫は、次のイベントを受け取ります。

...このイベントループを利用：

イベントループの実装はかなり簡単であることがわかりました。

しかし、基になるWindowオブジェクトをどのように作成する必要があるのか​​わかりません。NativeWindowクラスの実装は、私には複雑すぎるようです。

これが現時点での私の解決策です。

Windows 7 の Qt で支援が必要です。readyRead()非同期プロシージャ呼び出しによって Qt シグナルが発行され、コードが同時に実行されますが、同じスレッドで実行されるようです。

私の例では、ロックによってアクセスされ、DoRead()アクセスされるキューがあります。DoTimer()操作全体が ui (メイン) スレッドで実行されています。しかし、DoRead()いわゆるデッドロックが発生することもありました。コードは で実行を停止しDoRead()ます。メッセージ ボックスが表示されている場合は、デッド ロックが再現可能であり、実行DoTimer()が停止されます。OnRead()しかし、それがまだ同時に呼び出されていることに驚きました。私にとって唯一の説明は、それOnRead()が Windows APC によって呼び出されるということです。

MSDN の記事「非同期プロシージャ コール」を参照してください。

非同期プロシージャ コール (APC) は、特定のスレッドのコンテキストで非同期に実行される関数です。APC がスレッドのキューに入れられると、システムはソフトウェア割り込みを発行します。次にスレッドがスケジュールされると、APC 関数が実行されます。

readyRead()APCである可能性があるという私の仮定は正しいですか?

どちらの場合でも、デッドロックを防ぐにはどうすればよいでしょうか? DoRead()キューを埋めるためにキューにアクセスする必要がありDoTimer()、同じキューからエントリを読み取り、書き込み、または削除するために (もちろん他の方法でも) キューにアクセスする必要があります。両方の呼び出しが同じスレッドで発生するため、再帰的ミューテックスは解決策ではありません。

編集2：私が見つけたように、これはAPCとは何の関係もありませんでした。問題は、QMessageBox によって作成された余分なメッセージ ループだけでした。

QMessageBox を直接呼び出す代わりに、すべてのメッセージがキューに入れられ、キュー操作の後に表示されます。

キューへの同時アクセスがない (マルチスレッドでない) 場合、ロックは必要ありません。