HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2015
0419
TNKプロセス間通信15解決


TNK

リンク

2015/4/19(Sun) 22:20:37|NO.68656


sdim ln, 4096 ; #たぶん一回の受信物 sdim buf, 32000 ; #たぶん送受信物 sdim linin, 4096, 32 ; #lnを分割したもの sdim out, 4096, 1 ; #送信物 pipeexec buf, "***CUI.exe", 0 ; # if stat : dialog "実行できませんでした" : end repeat wait 1 ; # pipeget ln ; # if stat = 0 : break ; #実行終了ならループを抜ける (lnもあるかどうかも見なきゃダメかも?)。 if strlen(ln) > 0 { ; #受信物があれば受信 count2 = split_n( linin , ln ) ; #split_nは split ln, "\n", linin とほぼ同じ repeat count2 ; # bin linin(cnt) ; # loop; ; # ln = "" ; # } if strlen(out) > 0 { ; #送信物があれば送信 repeat strlen(out) ; # pipeput peek(out, cnt) ; # loop out = "" } loop mes "実行完了..." end

一週間ほどですが、HSPをダウンロードしてこの記述の中でHSPの動作確認をおこなってきました。
わけもわからず作った物ですので、正しく動作してるのかどうかがよく分かりません。
「表面上は」正しく動作していて、この一週間に問題はありません。

1:waitやstopは停止ではなく、一定時間GUIのイベント監視用のループに処理を返すと言う解釈でいいですか?
スレッドとかそうゆうのではないですよね?

2:bufとlnの具体的な違いが分かりません。
bufが受け取った全ての内容で、lnが一回に受け取る内容なのかな、と思っていましたが、どうもそうではないふしがあるようです。
lnはpipegetしても消えずに増えていくです。

3:lnが、改行やEOFを受け取ってないくせにガンガン代入されてるくさいです。
そうゆう時はスルーするよう、私が記述するべきなのでしょうか?
変な所でデータが切れないか不安です。

4:処理の中でlnを削除してますが、別に大丈夫ですよね?

5:これが最大の問題なのですが、pipegetとpipeputが全然対象パイプを指定していないように思えます。
パイプを二つ開きたいのですが、どうすれば…?



この記事に返信する


skyblue

リンク

2015/4/20(Mon) 16:35:33|NO.68667

>1:waitやstopは停止ではなく、一定時間GUIのイベント監視用のループに処理を返すと言う解釈でいいですか?
>スレッドとかそうゆうのではないですよね?
waitが一定時間処理を停止させてイベント監視用のループや他のプログラムに
CPUを明け渡す命令でstopが命令の実行を終了する命令的な感じで的な感じです。

>2:bufとlnの具体的な違いが分かりません。
>bufが受け取った全ての内容で、lnが一回に受け取る内容なのかな、と思っていましたが、どうもそうではないふしがあるようです。
>lnはpipegetしても消えずに増えていくです。
bufが標準出力の内容でlnがpipegetの処理の内容です。返却値を確認しましょう。

>3:lnが、改行やEOFを受け取ってないくせにガンガン代入されてるくさいです。
>そうゆう時はスルーするよう、私が記述するべきなのでしょうか?
>変な所でデータが切れないか不安です。
ヘルプによるとバッファーのサイズまでなので場合によっては切れます。

>4:処理の中でlnを削除してますが、別に大丈夫ですよね?
大丈夫ではありません。返却値を確認してから捨てましょう。

5:これが最大の問題なのですが、pipegetとpipeputが全然対象パイプを指定していないように思えます。
パイプを二つ開きたいのですが、どうすれば…?
パイプを内部で指定しているので大丈夫です。
2つ以上は無理です。HSPでは



TNK

リンク

2015/4/20(Mon) 17:34:34|NO.68669

>1
なるほど、そうですか。ありがとうございます。

>bufが標準出力の内容でlnがpipegetの処理の内容です。返却値を確認しましょう。
具体的な違いはなんなんでしょう?
とりあえず、容量に収まる範囲では常に同じになってますよね?

>ヘルプによるとバッファーのサイズまでなので場合によっては切れます。
それは存じておりますが、
質問で聞いたようなたぐいのデータの破損は起こらないのでしょうか。
(こちらでするべきなのでしょうか?やらなくていいのでしょうか?)


>大丈夫ではありません。返却値を確認してから捨てましょう
まずいんですか?
この記述で言うと、それが発生するのはどのあたりでしょうか? それについてはすぐ直します。

一応質問の意図としては、仕様による(例えば連結への参照など)パイプとの接続エラーなどを想定した質問です。



skyblue

リンク

2015/4/21(Tue) 07:34:14|NO.68678

>具体的な違いはなんなんでしょう?
>とりあえず、容量に収まる範囲では常に同じになってますよね?
返却値によっては標準出力と標準エラー出力、それ以外とpipegetの方は変わります。


>それは存じておりますが、
>質問で聞いたようなたぐいのデータの破損は起こらないのでしょうか。
>(こちらでするべきなのでしょうか?やらなくていいのでしょうか?)
詳しくは分かりませんが、メッセージの途中で切れてしまうとかだと思います。
なので何を破損とみなすかは分かりませんが上記の通りです。

>まずいんですか?
>この記述で言うと、それが発生するのはどのあたりでしょうか? それについてはすぐ直します。
エラーやパラメータエラーが分かりにくくなるので

>一応質問の意図としては、仕様による(例えば連結への参照など)パイプとの接続エラーなどを想定した質問です。
パイプとの接続エラーは起こりません。
すでに終了していたりする場合は返却値で判断できます。



TNK

リンク

2015/4/21(Tue) 09:46:28|NO.68680

ごめんなさい。
なにを教えてくれようとしてるのかが分からなかったです。
でもありがとうございます。



ooo

リンク

2015/4/21(Tue) 13:36:33|NO.68683

>1:waitやstopは停止ではなく、一定時間GUIのイベント監視用のループに処理を返すと言う解釈でいいですか?
>スレッドとかそうゆうのではないですよね?
あなたの言う停止の定義がわからないですがヘルプにあるように一定時間またはイベントが発生するまでスクリプトの実行を停止します。
停止している間はOSからのメッセージを処理してあなたのいうようにイベントの発生の監視もしています。
HSPはシングルスレッドで動作しています。

>2:bufとlnの具体的な違いが分かりません。
この辺はマニュアルに書いてないのでソースを見るか実際の動作から推測するしかないです。
以下は推測です。
・lnは前回pipegetを呼んでから今回呼びだした間にパイプに送られたデータが格納される。
・ただし何もデータがなかった場合はlnを更新しない。

>3:lnが、改行やEOFを受け取ってないくせにガンガン代入されてるくさいです。
>そうゆう時はスルーするよう、私が記述するべきなのでしょうか?
>変な所でデータが切れないか不安です。
ちょっと質問の意味が分からないです。
改行が送られるまでlnの更新を待ってほしいとかなら、そんな機能がない以上自分でするしかないです。

>4:処理の中でlnを削除してますが、別に大丈夫ですよね?
大丈夫だと思います。
というかそうしないとパイプに新しいデータが送らているか確認できない。

>5:これが最大の問題なのですが、pipegetとpipeputが全然対象パイプを指定していないように思えます。
>パイプを二つ開きたいのですが、どうすれば…?
pipeexexにはそんな機能がないので自分でAPIを呼んで書くしかないでしょう。
検索すればサンプルやモジュールとか公開されてるかもしれないです、


蛇足ですが
HSPにおいてはマニュアルにないことを実際に動作させて推測するのは普通・・・と思う。
すべてマニュアルに書いてないとおかしいとか考えてるなら向いてないかもしれないです。



TNK

リンク

2015/4/21(Tue) 14:09:12|NO.68684

>・lnは前回pipegetを呼んでから今回呼びだした間にパイプに送られたデータが格納される。
>・ただし何もデータがなかった場合はlnを更新しない。

なるほどそうだったんですか。
耐久テストを行なうとその時だけ挙動が不安定になってましたが、
症状が一致してきました。


>ソースを見るか実際の動作から推測するしかないです。
ソースあるんですか?気づきませんでした。
せめて普通のパイプかどうかと、受け取りと送信でプロセスを二つ用意してるのかどうかは知りたかったんです。



TNK

リンク

2015/4/21(Tue) 14:46:44|NO.68685

なんか今思いましたが、お二人とも私と同様、
lnを使う事を前提としていますが、もしかしてテスト以外であまりいじったり見たりしてはいけないデータなのでは…?
なんかそうゆう気がしてきたのでその方向でやってみたいと思います。



skyblue

リンク

2015/4/21(Tue) 16:11:31|NO.68686

>なんか今思いましたが、お二人とも私と同様、
>lnを使う事を前提としていますが、もしかしてテスト以外であまりいじったり見たりしてはいけないデータなのでは…?
自分に関してはそういうわけではありません。
ただソースに書いてあるから分かりやすいように書いているだけです。



TNK

リンク

2015/4/21(Tue) 20:51:55|NO.68691

特に気になる人もいないと思いますが、
根本的にlnを読み出しているのが間違いだったようで、耐久テストに引っかかった問題については全て解決されました。



zakki

リンク

2015/4/21(Tue) 20:59:11|NO.68693

この場合、lnは文字列として扱う限り好きに使えるけどbufはpipeexec呼び出し後にsdimしたり代入したりすると死ぬんじゃないかと。
最初に確保したバッファ分以上の出力があるとやっぱり死ぬのでデータ量が多いか不確定だったりネットワーク外部からのデータ扱う場合だとWindows API呼ぶか(なにか適当なのがあれば)他のプラグイン使うかhspext自体を修正するかしないと危なそうです。

http://dev.onionsoft.net/trac/openhsp/browser/trunk/plugins/win32/Hspext/appcapt.cpp#L437
のdosp_buf関連のあたり。



TNK

リンク

2015/4/21(Tue) 21:08:54|NO.68694

返信ありがとうございます。
つい先ほど、すでに対応致しました!

ただ、死なないようにすればそこまで危ないとは思わなかったので、
掲示板の過去ログのように保存する方式を取りました。



TNK

リンク

2015/4/21(Tue) 21:29:03|NO.68695

あ、でもlnを自前でstrcatするほうが安パイなのかも…
そうなるとbufはいったい…



ooo

リンク

2015/4/22(Wed) 08:17:30|NO.68701

>なんか今思いましたが、お二人とも私と同様、lnを使う事を前提としていますが、もしかしてテスト以外であまりいじったり見たりしてはいけないデータなのでは…?
別に前提とはしていないですがソース見たところ使ってはいけないデータではないです。
何をしたいかによって使う使わないを決めればいいでしょう。



TNK

リンク

2015/4/22(Wed) 09:48:19|NO.68702

へー、そうですか



ooo

リンク

2015/4/23(Thu) 09:13:06|NO.68710

はいそうなんです
あと、機能に不満がある場合は自分で作るのもいいと思います。
まあ精進してくださいな。



ONION software Copyright 1997-2023(c) All rights reserved.