Weekly PR #11 mutex vs channel
今週は2つ
1件目は、ritaというmongodbを用いたnetwork analyzer?のDBへの接続数をcofigurableにする改修をしました。
新しくStrobeという構造体を定義して、yamlファイルから呼び出すように実装しました。
デフォルトの値が決まっていなかったような設定がそこそこあったのですぐにはマージされませんでしたが…
2件目は、sqsxというamazonのメッセージキューイングサービスを使うためのライブラリ？ラッパー？のtestcodeに潜むrace conditionを修正するものでした。
consumeCountの排他処理に問題があるのはgo test -raceの結果を見た感じすぐに分かったのですが、mutexで直すかchannelで直すか悩んだ挙句、簡単なmutexで直す方法をとりました。それが上のPR。
そもそもchannelで直せるのかな？と力試しにやってみましたが、およそ黒魔術的な実装になりそうになったので、却下。でもforループのbreakやreciever blockingの勉強になりました。一応、channel版の実装も晒しておきます。
timerイベントと、consumeのfuncを実行した時にchannelを送信して受け取るイベントをfor-selectで実装するもの。timerイベントを受信するとforループをbreakするのだが、ただのbreakだとこいつを抜けることはできない。labeled breakを使わなければならないようです。これどう見ても言語のバグだと思うんだけど...
mutexの方が修正が簡単で良い感じ、testなので基本シーケンシャルな処理の中にあるチマっとしたコンカレント処理なので可読性もそんなに悪くはない感じです。channelの方が可読性というか読み通しやすさは高いのと、refactorする際にmodule化しやすそうな実装になっているように思えます。
