| ■6858 / ) |
Re[4]: Control.Invokeが使えない件。 |
□投稿者/ れい (61回)-(2007/08/25(Sat) 04:48:28)
|
■No6851 (渋木宏明(ひどり) さん) に返信
> 「Control.Invoke() の使用による不都合の原因は Windows のメッセージング機構に問題がある」という話だと思ってたんですが、そうではなくて「不都合の原因は Control.Invoke() の実装にあるのでは？」というお話なんですね？
そうです。
内部でAsyncWaitHandleをずっと待ち続けてるようなので、
■No6852 (NyaRuRu さん) に返信
> あと，単にメッセージポンプが止まっただけのような状況を私はデッドロックとは呼んでこなかったのですが，今回の件をデッドロックと呼ぶのは混乱の元だったりしませんか？
ポンプが止まってるだけではないですが、
おっしゃるとおり、デッドロックではないですね。
ロック持ち合ってるわけじゃないですから。
ハングですね。
■No6856 (渋木宏明(ひどり) さん) に返信
>>Control.InvokeはGUIが無くても止まりますので、今回はあまり関係ないです。
> GUI の無い Control.Invoke() ってどゆこと？？？
あっと、失礼。言葉が足りない。
Invokeされる側でなく、Invokeする側の話です。
Invokeする側はControlを持たないWorkerThreadでも、ハングします。
■No6854 (NyaRuRu さん) に返信
>>Control.InvokeはGUIが無くても止まりますので、今回はあまり関係ないです。
> うーん，本当に関係ないんですかねぇ？
> 私がいいたいのは GUI あるなしじゃなくて，メインスレッドにおける Application.Run(new Form1()); がワーカースレッドにないことの影響とか，ちゃんと考えました？ ということなのですが．
Appication.Runで何か特殊なことをやってるかもしれませんが…。
メインスレッドからサブスレッドのFormにInvokeしても、
サブスレッドからメインスレッドのFormにInvokeしても同じでしたから、
まぁあんまり関係ないかと思ってるんですが。
Application.Runが影響してるんだとするとかなり醜い実装ですねぇ。
■No6851 (渋木宏明(ひどり) さん) に返信
> きわどいタイミングでメッセージ伝達が起きないように VC++ を多用していた頃からオブジェクトの寿命管理を徹底しています。
私も結局自分で同期機構を入れてスレッド間通信してしまってるんですが、
せっかくあるのに、使いようがないというのが何とも気になります。
■No6855 (渋木宏明(ひどり) さん) に返信
>>あと，単にメッセージポンプが止まっただけのような状況を私はデッドロックとは呼んでこなかったのですが，今回の件をデッドロックと呼ぶのは混乱の元だったりしませんか？
> 例えば、ワーカスレッドでウィンドウを作ったとして、同じスレッドでメッセージポンプを回さないのはまずいすね。
> Control.Invoke() の実装が SendMessage() ではなく PostMessage() を使用しているなら、メッセージ送信先でメッセージポンプが回っていなければメッセージキューが詰まった時点でブロックかな？
> SendMessage() を使っていれば同期的に WndProc() が直接呼び出されるので、そういう「ふん詰まり」は原則おきませんが。
件のコードではShowDialogで回してます。
Control.Invokeの実装は間違いなくPostMessageです。
|
|
