今日の項目

6月23日の何か

ティアのたわごと☆其の４７３

DDEは初めていじってるんだけど
今一判らない内容が多い

いろいろと整っていて、メッセージもいろいろ飛んできて・・・
制御しやすいと思っていても、実際の所細かな動作がさっぱり判らない。

そもそも、常時接続していて良いのかどうか・・・・

大体ですね、
XTYP_CONNECTが来てから実際に接続が行われるXTYP_CONNECT_CONFIRMがくるまで・・・・

基本的な初期化は
XTYP_CONNECT
でするにしても、それ以外にも沢山する必要があったりとかで、
今時のマルチコア（デュアルコア）化が進んでいる現状としては、少しでも別々に動かしたい

XTYP_CONNECT自体がOSから呼ばれていると想っているあたしとしては、
アプリケーションのメインスレッドとは別に届くと信じていました。

だから、XTYP_CONNECTが来た後は、適度にフラグをセットして、受け入れ準備を開始させつつも、速攻でリターンしていたわけです。
メインループは一般的なWM_TIMERを使っていたのが悪いのかもしれませんが、それで初期化をする予定でした、

だから、XTYP_CONNECT_CONFIRMでは、逆にWM_TIMERの方での初期化が終了するときにセットするフラグ待ちをしていたわけです。

この短時間の中でどれだけ効率よくスレッドが回されるのかは微妙でしたが、でも、もしかしたら、プロセス間処理の合間に終了しているかもと思いました。

しかし違ったんです。

なんとですね、WM_TIMERは１個も来なかったのです。

なんだかロックしてるよな〜　って感じに今まで動いていたアプリケーションがすぱっと停まったのが第一印象でしたが、

ブレークをセットして、しばらく到着を待ったのですが、結局来ず

見た感じから言うと、DDE最中は他のメッセージは来ない


わざわざ初期化処理をウインドウループに持って行った意味ナッシング。

しかも結構いろいろと順番に動作するように同期制御を入れたから、元に戻すのも大混乱です。


で、はっきり言いましょう、
同じ様な命令が多くて判りません。

例えば、DdeAccessData
これを実行すると、指定したDDEのデータの場所が帰るので、ある程度条件があるとは言え、読み書きが可能になります。
まぁいわばダイレクトアクセス？

それに対して、DdeAddData　DdeGetData
指定したddeのデータに読み書きをしてくれる命令、まぁ安全面から考えればこれかな？


でも、DdeAccessDataに「データにアクセスするときはこれを呼び出して下さい」とだけ描いてあり、データアクセス用の関数として、DdeAddDataが紹介されていたら、

DdeAccessDataのあとにDdeAddDataをすると思わない？


後、ずっと気になっているのが　advise loop と言われる物

adviseとは忠告するとか、宣告するとか、通知するとか
多分、データを制御する上での、変更しますよ〜から変更終わりましたよ〜
までだと思う

でも、これの始まりと終わりが判らない。

クライアント側からサーバー側のDDEオブジェクトをいじるには
DdeClientTransaction
というメッセージがあって、これを利用することで、スタートから終了までいろいろ出来ます。
では、サーバー側は？
DdeAddData等で、随意にデータの変更が出来る
DdePostAdviseと言う命令もあって、データ変更したら実行してとか行ってるけど
（クライアントにはXTYP_ADVREQが送られるらしい）

じゃ〜、クライアントから、行きたいときにDdeGetDataで読みに行ったり、したら
もしかしたら、変更の最中（実施にメモリを書き込むのではなく、サーバー側でデータの変更が発生してデータを順次書き換えている最中とか）だと、データの整合が全く取れなくなるでしょ？

advise loopってものが物をいいそうなんだけど、結局どうやってそれをスタートさせて終了するのかは、サーバー側が判らないのが問題なのよ
XTYP_ADVSTARTそのものは、クライアント−＞サーバーオンリーで
逆向けの制御がどうすればいいのか判らない、
あくまで、XTYP_ADVREQが来るまでは、ノータッチが原則なのかしら？


もうね、何だか結果が分かってきたような感じはするけど、
一度だらだら打ち込まないと、今一整理が付きにくいのよ

まぁいいわ、そろそろちゃんと組み上がると思うから


--------------------------------
追加

あ〜判ったってば

DDEはとてもシンプルにサーバークライアント方式なのね
応答を待つサーバーは、クライアントの接続があると、提供するべき情報を用意し、
クライアントが開始させたadvise loopにて提供するべき情報を書き込み

クライアントは、必要な情報を読み込んだ後に、
advise loopを終了させる。

継続的にデータが必要なら、ループを終了させる必要はないでしょうが、
あくまでクライアントからの要求に応じることしかできない様です。

動作としては、
事前準備
　１．サーバー側がname登録
　２．コネクト待ち
実行時
　３．クライアントから接続要求
　４．サーバー側で、それなりに初期化
　５．クライアント側でadvise loopの開始を宣言
　６．サーバー側で、データを準備
　７．クライアント側で必要なデータを読み込む
　８．必要であれば、それ以外の動作も行う
　９．クライアント側でadvise loopの終了を宣言
１０．サーバー側で不要なデータ領域を開放
１１．必要であれば再度advise loopを行う
１２．クライアント側でddeの切断
終了時
１３．サーバー側でname登録の抹消
１４．サーバーソフトの終了

こんな感じかな？
いや〜、理解するのに長かったというか、最近の高機能なサーバーからすると、あまりにシンプルすぎて、機能不足が否めないというか、さっぱり理解していなかったというかｗ
まぁあまり悩みすぎるのは良くない


--------------------------------
追加２

未だ、ちょっと違った、
だいたい合ってるけどね、

６．と７．の間だけど、
サーバーでデータの準備が出来たら、
DdePostAdviseを実行するのよ、
そうすると、サーバー側のコールバックに
XTYP_ADVREQが来るから、データハンドルをリターンでは返すのよ
すると、クライアント側に
XTYP_ADVDATAが届くから、データを処理した後に、
DDE_FACK をリターンとして返す。

で、問題なのはDdePostAdviseを実行してから、XTYP_ADVREQが来るまでの時間

処理が長いとDdePostAdviseを送信したメッセージの処理が終了する前に、
callbackが起動されて（もしかしたら直後かもしれないけどね）、そのままクライアントへメッセージを送ってしまうので、これはこれで大変ですわよ


あ〜、そうそう、DDEがマジでWM_DDEXXXXっていうウインドウメッセージであることが判ったから、callback関数の最中にはWM_TIMERは発生しません。

後、DdePostAdviseを実行して、XTYP_ADVREQが来るのは、両方自スレなので、mutexが無意味orz
別の同期方法っていうか、同期取るとデッドロックするから、別の方法を考えないとね
DdePostAdviseを実行するスレッドは別に用意しようかしらｗ