Re: [MD:7043] Re: r3987 - trunk/src

[Shun-ichi GOTO <gotoh@xxxxxxxxxxx>]

>>>>> On Fri, 25 Nov 2005 18:44:38 +0900 (JST),
>>>>> 堀口 == Kyotaro HORIGUCHI wrote,

堀口> 訂正 & 追加

>  これは微妙なのですが, 複数の場所で行われています.

堀口>  これ以外には1箇所だけですね. カレットの処理でメインスレッドからウィ
堀口> ンドウプロシージャを呼び出すので一時的に W32_UNBLOCK_INPUT をして
堀口> います. (これをやったのは私ではないと思うのですが..)

これの善し悪しはわかりませんが、なんとなく間違ってそうな気がする。


堀口>  ところで, いま W32_BLOCK_INPUT の使われ方を見てみたのですが, これ
堀口> も WM_PAINT による expose_frame と他の描画処理を同時に走らせないよ
堀口> うにするものと考えていいのでしょうか.

正解は知りませんが、WM_PAINTに限らず、なんじゃないかなぁ。
Windows のWINDOW 情報とEmacs の frame 情報の同期が崩れないように
保護してる、とかではないかな。


堀口>  だとしたらこの状態からW32_BLOCK/UNBLOCK_INPUT を単純になくしてし
堀口> まうというもの手だと思います. W32_BLOCK_INPUT だと WM_PAINT をブロッ
堀口> クしてしまうのでメインスレッドの描画部からウインドウプロシージャへ
堀口> の処理の依頼を出す必要がある場合にデッドロックが起きがちになります.

堀口>  そして, このやり方を進めると結局フレームで管理すべき hdc はひとつ
堀口> だけにできるので全体がシンプルになると思います.

堀口>  過激すぎですか?

そうなると、branch でというのも検討した方が良いかも。
方針を(ある程度)かためて、branch をつくって、作業をして、レビューして
trunkに取り込むサイクルを作った方がよいかも。大きい問題があるようなら
trunk はrevert して更にbranch で作業を進める。
DCやBLOCK に関しては、理解とポリシーをもってやらないと泥沼ではないかと。

--- Regards,
 Shun-ichi Goto  <gotoh@xxxxxxxxxxx>
   R&D Group, TAIYO Corp., Tokyo, JAPAN