テキストエディタで各キー押しをあるスレッドから別のスレッドに渡すことはできますか？

Question

私は、再描画する領域、プラグインとの間のメッセージなどについての情報を渡すための内部メッセージキューを持つWin32コンソールのテキストエディタを実装しています。何も起こっていなければ、デフォルトではシングルスレッドであることが好ましい追加のスレッドが必要です）。

1. 使用汎用キューとWin32のイベントなので、私が扱うコンソール入力ハンドルとイベントの両方を渡し、同時に内部メッセージとユーザーの入力を待つWaitForMultipleObjectsExを使用することができます。私は2つのメッセージキューの実装戦略を検討しています。この場合、テキストエディタは1つのスレッド内に完全に存在することができます。
2. I/O完了ポートを使用します。この場合、テキストエディタには少なくとも2つのスレッドが必要です。そのうちの1つはメッセージを取得するためにGetQueuedCompletionStatusを呼び出し、もう1人はユーザ入力を入力してPostQueuedCompletionStatusによってキューに送信します。コンソールの入力ハンドルが重複できず、WaitFor*関数が完了可能なポートを待機可能なハンドルとして受け付けないため、同時に待つことができないためです。最初の設定と同じように、入力またはイベントがないときに両方のスレッドがCPU時間を無駄にすることはありませんが、各キーの押下はIOCP経由で別のスレッドに渡されなければなりません。

どのデザインが全体的に優れていますか？

テキストエディタで重要なIOCPを介して各キーを渡す際のパフォーマンスと遅延の問題はありますか？

Answer 1

IOCPのパフォーマンスと遅延は、目的に応じて適切です。しかし私は各キープレスをPostQueuedCompletionStatusに翻訳しません。私は、PostConnectionInputから何を得ても、複数のキー操作を一度にエンキューするためにPostQueuedCompletionStatusを使用したいと思います。

パフォーマンスの差はごくわずかだと思いますが、環境によってはどちらかが速くなる可能性があります。 WaitForMultipleObjectsは実装がはるかに簡単です。

P.S.メッセージキューはまったく必要ですか？これらの再描画要求/プラグインメッセージを、それらを起動したスレッドで処理しないでください。コンソール出力とあなたの共有状態をガードするクリティカルセクション？輻輳が100Hzのメッセージ+ 15Hzのキー押下のように低く、処理速度が速い場合、IOCPや他のキューよりも待ち時間が短縮されます。ロック/アンロック用のカーネル。これはまた、設計を簡素化します。あなたのメインスレッドはReadConsoleInput（）呼び出しをブロックする際にスリープします。その前にWaitForを呼び出す必要はありません。