投稿日: Feb 09, 2018 11:30:7 AM
今までの知識から考えるにスレッドかなーと思い。
golangでそれっぽいのを探るとgoroutineっていうのにたどり着き、確かにスレッディングだ。
でもそうじゃない。時間待ってくれればいいだけなのよ。
で、さらに探ると tickerってのがあった。
この手のものって大体ルーチンをコールバックするような形で動くのだけどgolangのはどうも様子が異なる。
goroutineと組み合わせて使っている例が多いのだけど、動作を見ていると不安になってくる。
tickerの処理を待っている間にループで何度もgoroutineが呼び出されているような。
そうなるとどんどんスレッドが肥大化して最後にはクラッシュするんじゃないかコレ。とかいう不安で心がざわめく。
で、そもそもtickerはどういう値を返すのかと思い。
tick:=timeNewTicker(time.Millisecond*100)
fmt.Print(tick,"\n")
fmt.Print(<-tick.C,"\n")
などとやってみた。
で、気づいた。
<-tick.C はウェイトになる。
つまり・・・
package main import ( "time" "fmt" ) func main() { ticker := time.NewTicker( time.Millisecond * 100 ) running := true count := 0 for running { _ = <-ticker.C fmt.Print(count , "\n") count++ } }
こんな具合にすると、forループの中で100ミリ秒毎に処理が実行されることになって、このコードだと100ミリ秒毎に数字がカウントアップ表示してゆく感じになる。
_ = <-ticker.C
この行がくる度にtickerの時間が経過するまで待ってくれるということらしい。
60fpsでの1フレームは16.6ミリ秒くらいだからその間完全に処理が止まっていようがそんなに困らないかもしれない。
またはこのループからgoroutineで各種処理を呼び出すというのも一つ手か。
つまり、
_ = <-ticker.C
go func1()
go func2()
のような。
※これ、少し試してみたけど呼び出すファンクションが複数ある場合goroutineでの呼び出しは順番が保証されないっぽい。
世の中のサンプルコードとはまるで手法が逆だけど、そういうのもアリなのかも？とか。
いや、golangの偉い人たちがどう感じるかっていうのはあるにせよ。手っ取り早くてシンプルな解決方法なのではないかなぁとか。