T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« Windows版を更新中 | トップページ | トランスポーターの変更を開始 »

やっと安定化できた

今は、Mirror-DTC Ver1.4.4の開発フェーズで、既にWindows/macOS用のβ1版を公開中だ。Mac版の次にWindows版のトランスポーターを更新しようとしたのだが、その前のサーバー更新で苦労した。

苦労させられた問題というのは、昨日書いていた様な問題になる。

つまり、本来の機能自体は動作していたのだが、その機能を停止させるのに苦労させられた。

具体的には、DTCServiceのオプションにある、接続中はサーバーの物理画面を黒くする機能のお陰で、リモート操作対象画面を切り替えようとすると、Mirror-DTC的には、その接続が切断される、事があった! 訳だ。

事があった! というのは、作者が不具合について記述する時に良く使うワードで、同じ様な操作を行っても、問題が発生する場合としない場合がある状況を意味している。

つまり、その問題を解決しようとしたら、まず、その問題を発生させなればならないので、苦労させられる訳だ。

今回の問題の場合、DTCServiceのオプションに関連しているので、VisualStudioをデバッグモードで動作させて・・・なんて事も出来なかった。

まあ、無理やり、デバッグ環境下で似た様な機能を動作させてデバッグする事は不可能でもなかったのだが、それをやったとしても、サーバー側の画面は真っ黒になっているので、VisualStudioの出力画面も見れない状況だった。

と、いう事で、苦労させられたのだが、自分で作ったコードなんだから、実機動作なんかさせなくても、ソースコードを見ながら、思考実験みたいな事をやれば、解決できるんじゃないの? と、思う人もいるかもしれない。

当然、作者が書いたコードに明らかなバグがあるのなら、コードを見ていれば、実機動作なんかさせなくても問題を解決できる場合も多い。

しかし、問題となるのは、作者が書いたコードだけではなくて、使用しているAPI関数にもある訳だ。

と、いうか、作者が苦労する殆どのケースはAPI関数絡みになる。

今回も、そうだったのだが、実験してみた結果、そのAPI関数は、少なくとも一時的には、メインスレッド、というか、メッセージキューを利用できなければ、動作できない! みたいな感じだった訳だ。

当然、マイクロソフトのドキュメントには、そんな注意書きは書かれていなかったのだが、実験結果から、それは明らかな感じだった。

具体的には、転送画面の切り替え時には、まず、画面転送用のスレッドを停止するのだが、その停止処理はタイマー処理の中で行う形になっていて、その後の処理を安全に行える様に、そのスレッドが停止した旨のフラグが立つまで、その処理の後半を待たせる様にしてあった。

しかし、色々と確認してみると、問題発生時には、その後半に処理が移行する事がなかった結果、タイムアウトが発生して接続が切断されている事が判った。

なので、作者的には、自前のコードには問題が無さそうだったので、危なっかしそうなAPI関数を使用しない格好にしてみた所、接続が切断される現象は発生しなくなった訳だ。

もっとも、この関数を使用しない事には、サーバーの物理画面を黒くしつつ、サーバーの論理画面を転送する! なんてアクロバチックな機能は実現できない。

このため、上記のAPI関数がどうしてクラッシュするのか? と、try-catch文を入れて例外が発生したら、その内容を確認しようとしてみたのだが、問題発生時にも、例外は発生していない様だった。

つまり、上記のAPI関数はフリーズしてしまった! 様に見えたのだが、過去の経験から、巷のソフトエンジニア的には、メインスレッドでないと動作しない! みたいなAPI関数を公開していたりしてきている訳だ。

上記は、特に、Linuxの画面制御系に多いのだが、今回の件も、画面制御系なので、もしかしたら、と、いう事で、前述のメインスレッドでのスレッド停止待ち処理を、もし、上記関数がメインスレッドを必要としていても問題なくなる様に、より複雑な形態に変更してみた所、問題は発生しなくなった。

と、いう事で、今回の問題は、メインスレッドでしか動作しないAPI関数が処理を終了してくれないと終了しない別スレッドに対する終了要求を出し、その終了を、メインスレッドで、待っていた! のが問題だった。

つまり、上記のAPI関数が処理を終えた後に、そのスレッドの終了要求を出せた場合には、問題は発生せず、処理を終える前に終了要求を発生させた場合には、デッドロックの様な状況が発生して問題になった、というのが、今回の問題の本質だった。

上記の様な問題は、いくらソースコードを見ていても答えは書かれていないので、API関数の挙動をテストしてみなければならない訳だ。

と、いう事で、今回は、デバッガーを動作させる事は出来ず、それ以前に、画面表示も見れない状況で、マイクロソフトが提供している公式APIが、何故かフリーズしてしまう! という問題が発生した。

なので、マイクロソフトが悪い! と、言うのは簡単なのだが、この問題を何とかできないと、困るのは自分になる。

何とも理不尽な話になるのだが、ハードウェアであれソフトウェアであれ、コンピュータエンジニアなら、こんな問題に遭遇するのは日常茶飯事の筈だ。

なので、コンピュータエンジニアに第一に要求されるのは、問題解決能力! という事になる訳だ。

« Windows版を更新中 | トップページ | トランスポーターの変更を開始 »

2024年5月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google