Re: [Kai-devel-ja] Fwd: プロセスプール [was Re: 開発の進め方]
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
From: Takeru I. <tak...@gm...> - 2008-06-29 14:20:41
|
>> 設定を動的に変更する予定はないですが,設定値というのはノード全体で共有されるのが素直な解釈なので,性能上の制約が明らかになるまでは【案2】のような複製は避けたほうが無難かなぁ. >> そうしないと,忘れた頃に誰かがデバッグで苦労しそうな気がしました. > > 今、コード読みはじめたばっかりなので、あまり大きなことは言えないですが、 > 常に設定サービスに問い合わせる場合、毎回同じあたいが返ってくるのか? ということを > 考えながらコードを追いかけることになるので、不変なのであれば、それが > コード上で明確になればいいなぁ、とおもっていました。 > # java なら final (ポインタの不変性) , Ruby なら定数(実は上書きできる) みたいなの それはそうだね. 僕は kai_config を書いた本人だから気にならないけど,他の人なら気になるかも. 実際,いくつかのモジュールでは設定値を変数に持ち直してループで繰り返し使っているところがある. これは,設定値が変更されないという前提があるからできてることだし. とはいえ final 的なことはできなそうだから,ドキュメントに "configuration values are never modified while running" とでも書いておくしかないかな. そして,「各プロセスでキャッシュしてよい」というルールにしたほうがいいのかなぁ. まぁ,細かいことだから神経質にならずにほっとくかぁ. >> リファクタリングの定石からいくと,同時に複数の機能を追加・変更するのはなるべく避けたほうがいいでしょうか (というか,僕はそうするのが好みなだけかも). >> そうであれば,TCP server を書いて,すべてのテストが通るのをコミットしてから,kai_config を修正したほうがいいかも. >> あるいは kai_config から先に修正するか. > > リファクタリングには機能の追加は含まれない、とか思想的なことはどうでもいいですが、 > たしかに、構造の変更と、機能の追加は分離すべきだとおもいます。 > ちょっとコード上の話にはまだきっちりついていてなくてすんません。 > > # 書いてる間にスレッドが更新されていく... > > shino > -- Takeru INOUE <tak...@gm...> |