[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
114(1): デフォルトの名無しさん [sage] 2019/11/26(火) 07:37:44.38 ID:wNKG8xXd(1/4) AAS
>>112112(2): デフォルトの名無しさん [sage] 2019/11/25(月) 22:57:11.50 ID:0VXwuJZP(1) AAS
ありがちなのはsigintしたときにすぐにプログラムを止めずに子のゴルーチンの処理が一区切りついてから止める場合とかかな🤔
んだね、自分はちゃんと後始末していることを保証するためにWaitGroupと組み合わせてる
121(1): デフォルトの名無しさん [sage] 2019/11/26(火) 22:53:16.65 ID:wNKG8xXd(2/4) AAS
>>120120(1): デフォルトの名無しさん [] 2019/11/26(火) 21:33:38.25 ID:+iLBHaU9(1/2) AAS
>>114
便乗して更に質問で申し訳ないが聞きたい。waitgroupって、個人的にはworkerの数が決まってるなら使うべき？
wg使わずにキャパシティ付きchannelに放り込む、クロージャでdefer closeしてその後channelをrangeで回す。というのもソースコードではよく見る。
ここら辺なにが正解なのかわからんのよね
workerの数が決まらないほど、使うべきなんじゃない？
要するに全部のgoroutineが終わったかどうか判断する仕組みだから
ちなみに自分はgoroutineを二段構えで呼んでて、WaitGroupは隠してる
外部ﾘﾝｸ[go]:github.com
124(1): デフォルトの名無しさん [sage] 2019/11/26(火) 23:23:41.57 ID:wNKG8xXd(3/4) AAS
>>122122(2): デフォルトの名無しさん [sage] 2019/11/26(火) 22:57:07.00 ID:eptCat3v(1/2) AAS
workerの数決まっていないでチャンネル使うとキャパシティ以上にワーカーできたとき詰まって死にそう🤔
WaitGroupのソースを参照
126(1): デフォルトの名無しさん [sage] 2019/11/26(火) 23:36:45.35 ID:wNKG8xXd(4/4) AAS
>>123123(1): デフォルトの名無しさん [] 2019/11/26(火) 23:23:09.81 ID:Gw3sx8bp(1/2) AAS
>>121
回答とサンプルありがとう。
質問の日本語がおかしかった。。
なるほど、こうすればchannelで送受信しなくても逐次的に処理できるということか。
ちなみにworkerの数が決まらないケースって、どんな場面で遭遇する？
常駐してて死なないアプリ以外にあんまり思いつかず
常駐じゃなくても並列処理で足並み揃える時とかに使うかな
例えば並列で別のダウンロードさせたり
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.046s