【プラグイン】WebSocket

WebSocketのサーバー/クライアントです。

https://miyako.github.io/2019/07/11/4d-plugin-ix-websocket.html

宮古さん

WebSocketsは「リモート環境を求める人々」に有効的ですね。
私も以前WebSocketsを4Dで実験したいたことを思い出しました。

そこでORDA環境になったのでこのプラグインを活用してサーバ・クライアント間のメッセージング機能を設けたいと試しています。

そこで以下のことを解決しなければならなくなりました。

サーバ側は準備が整っているとして、
メッセージング機能をアプリケーションを立ち上げている間有効にするため、
例えばOn Startupで

$client_o:=Websocket client($config_o) // クライアントオブジェクト生成
$status_o:=Websocket client start($client_o) // WebSocketクライアント開始

Use (Storage.config)
Storage.config.ref:=$client_o.ref
End use

とし、例えばOn Exitで
$client_o:=New object("ref";Storage.config.ref)

$status_o:=Websocket client stop($client_o)
Websocket client clear($client_o)

としてみました。
4Dを終了しようとすると「Tasks Pending」が出てきてしまい、キューの役割をしているローカルプロセスに絡んだエラーだということがわかります。

色々と試してみると、同じプロセスでスタートし、仮にステップを入れてPause状態にしてからストップさせると正常に終了するのですが、その他のプロセス（例えばウィンドウを表示するとか）などを実行して、ストップを実行させたのちに4Dを終了させると「Tasks Pending」となってしまいます。

同様のことをサーバのOn Server startupとOn Server shutdownで行っていますが、こちらは正常に終了します。

クライアントの場合、何か注意する点はあるのでしょうか？

On Exit ($xx) プロセスは，StorageやSignalなどもつぎつぎと消滅してゆきますし，もう『閉店』に取り掛かっているので，プラグインコマンドを実行するには，遅すぎるタイミングかもしれません。

Clearは，プラグインの終了処理でもしていますので，最悪，省略しても大丈夫だと思います。

Tasks Pendingはタイミングの問題かもしれません。
On Exitからローカルプロセスを呼び出してStopしてみるのはいかがでしょうか。

On Exitは例としてあげたのですが、On Exitのケースだけでなく、やはりタイミングの問題なのでしょうか、いくつか試したケースでもTasks Pendingとなってしまいます。

もう少し検証して報告します。

v18 R4でdemoと同様にフォームを開きclientをスタートさせフォームを閉じるところでclientをストップするだけの場合は、4Dを閉じる際に（多分キューのローカルプロセスを閉じているのでしょう）問題はありませんでした。

立ち上げの際にLogプロセスなどのフォームを表示させないワーカーのみが立ち上がっているのですが、正常に終了されます。

ところが、Websocket clientを一切スタートさせことなく（コマンドを使わず、つまり上記のようなことをしない場合）プラグインがインストールされているだけで、別プロセスでフォームを表示させると、例えば住所録を表示させるプロセスを立ち上げると、4Dを終了する際に、そのプロセスをKILLしたとしてもTasks Pendingが現れ、キュープロセスが動いたままだとのアラートが表示されます。

つまりプラグインをインストールするだけでキュープロセスが開始されるので、他のプロセスがらみでキュープロセスが閉じなくなってしまったのではないかと考えられます。

なんとかこれを解消したいと思うのですが

状況を整理できればと思うのですが，Task Pendingが発生するのは・・・

* プラグインをインストールしただけのアプリケーション
* クライアント/サーバー版のクライアント側
* サーバー側あるいはスタンドアロン版では問題ない
* WindowsおよびMac

で間違いないでしょうか。

確かにクライアント/サーバーのテストはあまりしていませんでした。

Windows版の場合

exeと同じ階層に"noThreadedFibers.prm"という空のファイルを置くと，
v17以前のスレッドモードになります。

逆にv17では"threadedfibers.prm"という空のファイルを置くことにより，
v18以降のスレッドモードにすることができます。

モードの違いは，パフォーマンスなどではなく，Visual StudioのデバッガやWindowsのダンプファイルに4Dプロセスがスレッドとして表示されることがおもなメリットであると聞いています。スレッドの独立性が高いために，プラグインが起動したスレッドなどとうまく連携して終了することができない・・・のでしょうか。

前の方のカキコミで

デザインモードからフォームを実行した場合（つまりMain process，プラグインのスタートアップやエグジットも同じスレッド）であれば問題なく，ユーザープロセス/ワーカーで問題がある，とのことでしたので，

プラグインのAPIをメインスレッドからコールするようにC++側で変更できると思います。

その場合，オブジェクト型やコレクション型が（記憶では）使用できなかったはずですので，内部的にJSON文字列に変換し，元に戻す，といった大幅な書き換えが必要になります。少しお時間をください。

ちなみに，4DのほうでもCALL WORKER(1) とSignalを使用し，プラグインコマンドを常にメインスレッドから呼ぶ，という手も打てるかと思います。プラグインの作業を待てない場合・・・

https://blog.4d.com/easily-synchronize-your-processes/

単体のMacとWindowsで別プロセスでフォームを表示させた場合、両方でTasks Pendingが出てしまいます。

SignalオブジェクトはV17Rでプリエンプティブのシステムを動かすときに非対応のプラグインだったかを使うために使ったことがあります。

とりあえずメインスレッドから呼ぶようにやってみます。

Signalを使ってMacとWindows色々やってみましたが、フォームを表示するワーカーを実行した後はダメでした。

ちなみにフォームプロセスはメインプロセスでしたので、他のプロセス名に変えて行いましたが同じ結果でした。

さらに試してみます。

取り急ぎ，イベントキューのループ脱出条件に

PA_IsProcessDying()

を追加してみました。

---

4Dの無限ループ処理でも，
インタープロセス変数のようなフラグだけでは不十分で，
Process abortedを絶えず確認する必要がある，
といわれますが，
ワーカーが関係する場合，
プラグインでも同じことなのかもしれません。

https://github.com/miyako/4d-plugin-ix-websocket