HSPTV!掲示板

スレッド一覧 | 新規書き込み | 新着一覧 | 使い方 | 過去ログ

未解決

解決

停止

削除要請


	2022 1211	大富豪	wait time がおかしい	20

大富豪

2022/12/11(Sun) 17:51:28|NO.97506

wait が待ってくれません。

例えば、wait 100 くらいにしても一瞬で処理が進みます。
設定した数値が1/10ほどに短縮されているような感じで
wait time が早くなっています・・・。
(wait 1000 で約1秒間)

なぜでしょうか。

win10でインストール後数年使っていますが
ここ数か月でそういう現象が増えてきました。

PCを再起動すると元に戻っていたのですが、
最近は常におかしいです。
エディターは 3.51 です。

この記事に返信する

zrs90(5さい)

2022/12/11(Sun) 20:20:20|NO.97507

私の場合、1秒なら、wait 命令より精度の高い
await 1000 使って終わりにしてしまいますが...
コレはご存知の上で質問されていると思います。

タイマー　精度
または
wait　精度

...で、サイト内検索すると、大体の理由が
分かるかと思います。

メルクーフ

2022/12/11(Sun) 21:17:36|NO.97508

　原因と解決法が分からないのでほとんどお役に立てませんが、私もWindows 10で同じ状態になったことがあります。

red氏のゲームで遊んでいた時に最初は同氏の待ち時間が短いだけなのかと思っていましたが、その後で自分の環境ではwaitがawaitみたいな挙動をしていることに気がつきました(awaitは平常どおりでした)。
https://dev.onionsoft.net/seed/info.ax?past=1892

　この後Windowsの更新をするとwaitの働きが元に戻りましたが、しばらくするとまたawait並のスピードになり、そのくり返しが何度か続いてからそういうことが起こらなくなりました。

　こういうことがあったので現在では基本的にwaitは使わないようにしています。

大富豪

2022/12/11(Sun) 21:46:08|NO.97509

＞zrs90(5さい)さん
＞メルクーフさん
お二方ご回答ありがとうございます。
精度というより明らかに不具合ではないかと；
５年以上も何もなかったのに何故最近になって、
という感じです。windowsの影響でしょうけど。
PCへの負担が気になりますが、
awaitを使ってみようと思います。

zakki

2022/12/12(Mon) 00:58:17|NO.97510

とりあえずの対処としてはWindowsをShift押しながらシャットダウンや再起動すると解消しませんか？

もしそうなら、たぶんこれと同じ問題でWindows Updateの時だけ完全な再起動がかかる以外の時は
サスペンドになってて経過時間がリセットされず32bit整数のオーバーフローが起きてるんじゃないでしょうか。
http://hsp.tv/play/pforum.php?mode=pastwch&num=89231

OS起動時点基準ではなくLinux版みたいにHSP起動時点を起点にするか、
オーバーフロー検出するか、GetTickCount64使うかでどうでしょう？
https://github.com/onitama/OpenHSP/commit/94a3535997b221c131702f259027fe0a6d0e8628

ze-na

2022/12/12(Mon) 08:17:37|NO.97513

>大富豪さん

以下スクリプトで timeGetTime値（Windows起動経過時間）を確認してみて下さい。
マイナス値なら zakki さんの書き込まれている症状の可能性があります。



#include "winmm.as"
mes timeGetTime()

これが原因であれば、3.6 beta3以降の利用で改善される可能性があります。

3.6 beta3 history.txt
>500時間以上起動したPC上でwait,await命令の待ち時間が正しく反映されなくなる不具合を修正

大富豪

2022/12/12(Mon) 21:43:18|NO.97518

＞zakkiさん
ありがとうございます。
気になるのが数年使っていて正常なのが、
最近増えた症状という事ですね。
もしかすると再起動ではなく電源を落とさないとリセットされない
というアレですかね；様子を見てみます。

＞ze-naさん
ありがとうございます。
500時間以上も起動しては無いのですが、
マイナス値になっていました；
エディターを更新してみようと思います。

zrs90(5さい)

2022/12/13(Tue) 05:32:10|NO.97521

zakki さん、ze-naさん、メルクーフさん
ありがとうございました。

私、wait 命令とawait 命令は
PCの負荷も最近の機体ならほぼ問題ない上
命令の仕組みが違うので、漠然と時間管理の
必要な所だけ、await 命令を使ってました。
（※ awaitでも厳密とは言えないのですが)

zakkiさんの提示先のスレッドを追っていくと
osや電源設定による様ですが、os再起動したつもりが
ただの復帰に近い状態になっている事も
初めて知りました。

約25日osを稼働させた状態のPCが
そうあるのかな？と思いながら
ウチで電源入れたままの
Windows7 pro32ビットの機体で
ze-na さんの提示されたスクリプトを
動かしたら、マイナスが出ました。(！）

...で、pcのお掃除ソフト使った後
再起動したら直ってました。
時々、このスクリプトでosの稼働チェックを
していこうかと思います。

>3.6 beta3 history.txt
>500時間以上起動したPC上で
>wait,await命令の待ち時間が正しく
>反映されなくなる不具合を修正

...と言う事は、大富豪さんの環境（3.51）では
私が投稿した、 NO.97507自体、意味がなかった
可能性が高いです。申し訳ないです。

また、この件、3.7β版のスレッドで検証
されていた方が見えたかと思います。
（※検証には時間がかかる物なので結果が
どうなったのか？までは不明ですが)
すっかり失念しておりました。

zakki

2022/12/13(Tue) 08:06:19|NO.97522

以前修正されてたような気がしたけどLinux版だけだっけとgitへのリンク張りましたが、
Windows版も3.5だと再現して3.6や3.7β2だと大丈夫なので修正済みですね。

大富豪

2022/12/13(Tue) 10:47:11|NO.97523

☆皆さま方、色々ありがとうございます。

30分ほど電源を落とし、起動後5分ほど後に
timeGetTimeを見るとマイナスになっていました・・・
(3.51のエディターで確認)

win10でずっと問題なかったのが最近のアレですので
やはりwindowsUpdateの影響の気がしますが、
時間がある時にエディターを更新したいと思います。
お騒がせしました；

TOMATO

2022/12/13(Tue) 11:58:47|NO.97524

>30分ほど電源を落とし、起動後5分ほど後に

"シャットダウン"ではなく"再起動"でやらないと意味ないです。
"再起動"でないと起動カウンタが0にリセットされません。

大富豪

2022/12/13(Tue) 13:08:07|NO.97525

＞TOMATOさん
はい、電源を落としても
waitTimeは改善せず、
timeGetTimeはマイナス値になりました。

win10で数年間おなじエディターを使ってますが、
waitTimeがおかしくなったのは最近です。

PCの起動経過時間と、
HSPのwaitの関係がよく分かりませんが、
たぶんwindows10の更新の影響ではないかと。

TOMATO

2022/12/13(Tue) 14:50:42|NO.97526

確認ですが、再起動の方法はどうやってます？

Windows 10の場合、"シャットダウン" と "再起動" は全く異なる仕組みです。
https://www.itmedia.co.jp/pcuser/articles/1808/20/news095.html

ですので、やり方をミスってると"再起動"になっていない可能性があります。
シャットダウン後に30分放置して起動と書かれていましたが、この方法で"再起動"にはなりません。
Windows のシャットダウンのメニュー内の"再起動"を選んで実行する必要があります。

大富豪

2022/12/13(Tue) 15:06:56|NO.97527

＞＞TOMATOさん

最初のコメントから時系列を追って頂くと
なんとなく分かると思います。

＞＞"再起動" をしてください。

・シャットダウンからの電源OFF
・電源ONのまま再起動

既に両方を試みていますが、
どちらも改善していません。

＞＞30分ほど電源を落とし、起動後5分ほど後に起動しただけでは、

起動の主語がもしPCの事でしたら前記の通りですが、
私が書いた文章の主語はエディター3.51です。

Rep.
『30分ほど電源を落とし、起動後5分ほど後に
timeGetTimeを見るとマイナスになっていました・・・
(3.51のエディターで確認)』

TOMATO

2022/12/13(Tue) 16:22:38|NO.97528

>最初のコメントから時系列を追って頂くと

それはわかってます。が、
"再起動"と書きつつも、実は"シャットダウン+電源ON"という操作をしていた方が結構多いので、
念のための確認で書いております。

マイクロソフトさんがツイートを書くぐらい、間違えている方が結構多いですので。
https://twitter.com/MSHelpsJP/status/1030008766757044224

---
結局 "再起動" でもダメだったということで話を進めます。

下記スクリプトを実行して、Windowsが起動した時間がどうなってるのかは気になるところですね。
その日時に心当たりがあるかも気になるところ。



#include "hspext.as"

	keywords = "システム起動時間"
	cmd = "systeminfo"
	sdim ln, 4096
	sdim buf, 320000

	pipeexec buf, cmd, 1
	if stat : dialog "実行できませんでした" : end

	repeat
		pipeget ln
		if stat == 0 : break
		await 10
	loop

	notesel buf
	repeat notemax
		noteget tmp, cnt
		if 0 <= instr(tmp, 0, keywords) {
			mes tmp
		}
	loop

高速シャットダウンを無効化したら、どうなるかも気になるところです。
https://www.fmworld.net/cs/azbyclub/qanavi/jsp/qacontents.jsp?PID=6010-9312

大富豪

2022/12/13(Tue) 18:29:04|NO.97529

＞TOMATOさん
なんと！？
そのソースはどういう意味ですか？

一か月以上前の日付けになってますが・・・
実は起動時間がリセットされていないという事ですかね。
しかし、wait timeが早くなる現象とどんな関係が・・・？

電源オプションは怖いので実施していません。

zakki

2022/12/13(Tue) 20:51:42|NO.97532

waitする必要なくてすぐ次の処理をするを waittick = -1 で表現していて
その判定が waittick < 0 だったので現在時刻が負になると常にwaitの必要無しと
判定されてたというhsp処理系の実装の話です。

基本的には発生しづらい条件で見つかってなかったのが
Windows 8以降のシャットダウンの挙動変更で顕在化したので修正された形だと思います。

https://dev.onionsoft.net/trac/openhsp/changeset/1082/trunk/hsp3/hsp3code.cpp

ze-na

2022/12/14(Wed) 00:54:05|NO.97537

>大富豪さん

>一か月以上前の日付けになってますが・・・

PC環境やWindows10の状態など人それぞれなので何ともですが
再起動時に前回起動時の情報が引き継がれるとかですかね？

Windows周りの話であれば、ハイバネーションの設定や
コンパネの電源とスリープボタンの設定やシャットダウン設定を
確認するくらいでしょうか。

>zakki さん

hsp3code.cpp 見ましたけど、まだ潜在がありますね。
waittickがプラス値で次のtickがマイナス値になると
復帰条件が厳しくなってウェイトのままとなりそうです。

waittick/tickプラマイ境界でawait/waitが実行される
必要があるので発生率はとても低いですが、

最近のノート/タブレットPCなどは、スマホと同じで連続稼働が
常識となりつつあるので発生する可能性はありますね。

大富豪

2022/12/14(Wed) 11:58:03|NO.97538

＞zakkiさん
なるほどです。
よく分かりませんがなんとなく分かりました；
windowsの状態によってHSPのwait命令が
ウェイトする必要無しと判断していた、ということですね。
(大きな数値にすると多少ウェイトしているようでしたが)

＞ze-naさん
windowsを落としても、
時間の情報がリセットされていなかったという事ですかね。
どんな電源の落とし方(再起動)をすれば起動時間の積算が
リセットされるのかは分かりません；

★皆様大変お騒がせしました。
＞zrs90(5さい)さん、zakkiさん
のエディターのバージョンの件、
3.6に更新したところ、あっさり普通の状態になりました；
今時3.51というのが古くてアレだったんですかね；

皆さまご対応頂きありがとうございました。

窓月らら

2022/12/15(Thu) 03:13:18|NO.97539

解決済みですが、この問題（基準にしているタイマーのあふれ問題）
については私も指摘してありまして
その時点で既に修正は入っていたのですが、デバッグするには
Windowsをかなり放置しないとわからない問題のため
実際のテストで本当に直ったか確認はしていないのですが・・・

皆さんご指摘のとおりHSP 3.6～にすれば一先ずは解決なのですが、
HSP 3.51 はexeのサイズが100KB以上小さくできるメリットもあります。
なので、私はもっぱらWindows用ソフトはいまだにHSP 3.51なのですが
wait命令に問題があるため Windows API の Sleep に置き換えて対応しています。
Sleep にもあふれ問題があったら終わりですが、
さすがにそれがあったらWindows側のバグなんで無いはず・・・



#uselib "kernel32.dll"
#func global Sleep "Sleep" sptr	// Sleep
#uselib "winmm.dll"
#func timeBeginPeriod "timeBeginPeriod" int
timeBeginPeriod 1	// Sleepの精度を1msにする(awaitと同等、実際は環境により多少ばらつきます)

repeat
	redraw 0
	color: boxf: color 255,255,255
	pos 16,16: mes cnt
	redraw 1
	wait 0: Sleep 16	// wait 0 はOSに制御を渡すために必須です
loop

注意点としては timeBeginPeriod 1 は他のアプリにも影響することです。
1msにすると負荷が上がりますが、いまのPCでこれが問題化することは
まずありません。15年前のシングルコアなノートPCでも問題になってません。

大富豪

2022/12/15(Thu) 17:29:26|NO.97541

＞窓月ららさん
ありがとうございます。
なるほど・・・奥が深いですね；
勉強になります。