読了: 『Go言語による並行処理』
読みました。ちょっと駆け足気味だけど。
全体的に良書でこういったことが知りたかったんだということが書いてあってよかったです。一方で悪い点もほんのちょっとありました。先に悪いと思っている点について書いておこうと思います。
悪かったと思った点
まず、interface{}
型の利用は、うーん、やめたほうがいいんじゃないの、という感じです。まあこれは補遺Bにより訳者の方による go generate の利用の推奨などもありまあええやろって思いました。
また、 done
チャネルの利用は、context がある程度普及している昨今ではかえって混乱を招いたのではないかと思います。最初の1例は「お、これ context の本質を捉えてていいな」と思ったのですが。エラー処理も pkg/errors でよくね?と最初は思ったのですが、そちらはいろいろ学びがあったので、逆に done についての煩雑さが目についたというのもあります。
まあこれらはどちらも個人の趣味の範疇かもしれません。そんなに目くじら立てるようなことでもないでしょう。
これは本文とは関係ないのですが、DLしたPDFファイルの outline が iOS 上の GoodNotes というアプリでは部分的にしか解釈できてなかったようです。これはアプリ側の問題の可能性もありますが。ちょっと読書体験が悪かったです。
良かったと思った点
まず「並行」「並列」について。僕はこの本で出てきた説明が一番しっくりきました。曰く「並行性はコードの性質を指し、並列性は動作しているプログラムの性質を指」すとのことです。以前にはおそらく Rebuild.fm でささださん達が説明されていた回で聞いていたのですがその後あまり意識することがなくうろ覚えになっていました。今回のこの説明は結構すんなり納得できました。
エラー処理や流量制限については現在 go でなにかを書いてる身としては参考になりました。実際運用するとこういうことありそうだなーとか不安になったりしてね……。はい。「ゴルーチンの生成コストとか気にすんな」という話はもともと繰り返し出ていて「いやでも無限に生成できると、DB詰まったりとか考えるとそこの生成数とかに制限かけないと安定しなくね?」みたいなことを思っていましたのが流量制限に集約していたのだなーと気づきました。
チャネルの所有権を曖昧にしないことや正しくリソース管理する点についてのイディオムというか、お作法について明に暗に示されていたのもよかったです。構造体のメンバにするなとか、レキシカル1に縛っておけとか。
p.32 からはじまる「チャネルを使うかどうか」という決定木や4章の各種パターンは有用そうなので忘れた頃に確認したほうが良さそうですね。チームでの読み合わせなどをしたほうが良いかもしれません。
読書メモ
コピらずメモったので原文と表記が違うかもしれません。
p.39
結果としてゴルーチンは、暗黙的には並行処理の構成要素ですが、並行性というのはコルーチンの性質ではありません。
各コルーチンを逐次実行するような処理系もありうるから、かな?
ゴルーチンはグリーンスレッドにスケジュールされます
へー。これ知らなかった。6章で解説あり。
p.53 あたり
Cond いまいちよくわからない
p.68
無名ゴルーチンが終了するとき
言語仕様的には無名ゴルーチンが終了するのと stringStream
からの読み込みでブロックするのはどっちが先かわからないのではないか、と思った。些細な点だけど。
p.74
くっそどうでもいいが出力結果がおかしい。実装してみたのが以下。
chap4.1 全体 あんまりよくわからなかった
p.123
同じ型の2値を戻すとき、名前付き戻り値を _
で受けることによって型を2回書かずに済むというテクを覚えた(おそらく使わない)。
scope 切って一回変数にうけてから chan 型変数を nil 代入して処理済みを表す、というテクを覚えた。これは使うかもしれない。
p.132
リトルの法則について、総和をとってよいのかはあまり自明ではないのでは?と思った。各パイプラインは、直前の例のように重なり合うことが可能なので単純な足し算にしてよいのか、という点が疑問として残る。リトルの法則自体はある程度独立したトピックなので後で調べるかも。
p.207
「プログラムがゴルーチン内の関数に実行してもらいたいと思うのはよくあることでしょう」の文意がとれなかった。前後の流れから、「作ったゴルーチンをすぐに実行してもらいたいと思うのはよくあることでしょう」という感じだろうか。
20181028 19時過ぎ
誤字脱字系は本家サポートレポジトリで issue 化したので読書メモから消した