#それです。DLS2008で見たんだったっけな。
#これいいですね。引っ越しが終わったら買うかも。
#gosh> (^ _ ^)
#<closure #f>
#ワロタ
#gosh> (^ _ -)
#<closure #f>
#これもあり
#(^_ までは連続できるけど、その後ろはスペース開けないとだめなのが惜しい(なにが)
##3Dモデラーの求人です。 RT sasaharakazuya: 3dsＭＡＸでモデリングできて、ＩＬＣＡで働ける方、引き続き募集中です～。スキルはそれほどは求めませんっ！
#control.thread-poolのadd-job!って何でタイムアウト指定できるようにしなかったんだっけな(キューが一杯なら直ちに#fが返るようになってる)。他のマルチスレッドAPIとの一貫性からすれば、デフォルトではキューが一杯なら無制限待ちで、それが嫌ならタイムアウト指定させるって方がいい気がしてきた。
#元になったkahuaのthread-poolniha
#元になったkahuaのthread-poolには最大バックログ長って概念が無いから、control.thread-poolを作る際に私が考えたAPIだと思うんだけど、何を考えていたのかよく覚えてない。
#今、既にadd-job!がキュー一杯の場合に待たずに#fを返すことに依存してるコードってあるかな? 無ければ非互換だけどAPIを変更してしまった方が良い気がする。Kahuaの今の使い方には影響を与えないはず。
#デッドロックが怖かったとか
#trunkからのリリースはしていないので、仮にKahuaに影響があったとしても対応しますよ
#BACKLOGのサイズ、という考え方からすると、BACKLOGが埋まってた場合はBUSYが返るのが自然だと考えたんじゃないでしょうかね
#socketだとそういう考え方だし
#使い勝手からすると、直ちにbusyが返ってくる場合、リトライしたかったらcaller側で少し待つロジックを入れなくちゃならなくて、caller側でも忙しくループ回してる場合は単純にsleepできないから結局キューみたいなものを持つことになる。でもpool側でもキュー持ってるから無駄だよな、と。
#あ、いや、例えば、HTTPサーバをこさえた場合だと、プールのbacklogがいっぱいだったらすぐにクライアントにエラーを返すとか、そういうのが念頭にありました
#もちろん、カスタマイズできればどちらがデフォルトでもかまわないのですが
#確かにtimeout引数を取るようにすればどっちにも設定可能なんで、むしろデフォルトの問題か。他のスレッド関連APIはデフォルトでブロック、すぐに戻りたければtimeoutに0を渡してね、っていうん思想だから、それに合わせたいっていうのが大きいな。
#であれば、そろえちゃうのが吉だと思います
#MLで聞いてみた。
#enqueue 待ちさせるなら terminate-all! するときにその人たちにも帰ってもらったほうがいいでしょうね。
#それは良い考えだ。とするとadd-job!の戻り値として、「無事キューに入った」「タイムアウト」「受付終了」の3つが区別できないとだめかな。
#最後のケースでは、raiseしちゃってもいい気が
#タイムアウト無しでadd-job!した人は正常に返ってくることしか考えてないからraiseの方がいい?
#そう思います
#ですね。
#mt-queueの方に、pthread_cond_waitで待ってる人たちに異常状態を通知する仕組みが必要か。今はその手段がない。
#あるいは thread-pool の方で以降の add-job! は失敗させつつ、queue にある分とその時点で待っている人の job は実行してあげるというやり方もありかも。
#今は一応キューに入った分は実行しようとするはず。キューに入った分っていうのは「受け付けました」って情報を返しちゃってるから。ただ、それでも時間がかかりすぎると強制終了モードに入るけど。
#queue にある分はいまでも実行しているので、そんなに変ではないはず。
#あれ、強制終了なんてありました？
#かぶった。terminate-all!に:force-timeoutを渡すと、それまでに返事を返さないスレッドについてはthread-terminate!しちゃう。
#ただ、これは危険な処理だから、サーバ自体のシャットダウンとか、状態がどう壊れても後に何もないから構わない、っていう場合のための措置。
#force-timeoutの処理自体、あんまり厳密じゃないし。最低こんだけ待ちますよ、程度の指定。
#なるほど、となるとやっぱり mtqueue のほうで待っている人にもう受け付けないことを知らせる仕組み入りますね。
#やっぱりspam emailって減ってたんだ。フィルタで弾いてるにせよ、最近すり抜け数も少なくなってきたような気がしてたんで。 http://www.bbc.co.uk/news/technology-12126880 #去年の今頃は Gmail の spam フォルダ（30 日以上経ったメールは自動的に消される）に常時 1 万通くらいたまってたのが、いまは 6000 通くらいです。
#昨日のthread-pool関連を考えてるうちに、「最大長==0」の<mtqueue>ってデータをバッファせずにproducerからconsumerに渡すのに使えるんじゃね、と思い始めた。今はmax-lengthを0にすると最大長無制限としてるので、最大長0を許すとすると非互換な変更になるんだけど。詳しくは http://blog.practical-scheme.net/gauche?20110107-zero-length-queue #一度キューに入っちゃうとconsumerしか取り出せないのでタイムアウトがかけづらい、長さ0にしておいて、キューに入れるところで待つようにすればタイムアウトかけられるよね、という話。ただそういう使い方だとproducerが一定時間ブロックするから、実はあんまり需要が無いかもしれず、思案中。
##ふむ。これは通常のキューとは別のクラスにしてるわけだな。
#Javaの場合は内部実装でもキューのクラスを分けてるみたいだから、実装が異なるSynchronousQueueだけ別にするのは自然だな。
#そもそもmake-thread-poolの実装とドキュメントに齟齬があったのに気づいた。今まで指摘が無かったってことは誰もmax-backlogの機能を使ってないってことだな。ってことはadd-job!の変更も影響範囲はほとんど無さそうだ。
#Javaだと実装が違うものはクラスをわけて、同じインターフェイスを実装しておくというのが自然みたいですからね。
#SynchronousQueueでコード検索したらユースケースが見つかるかも？
#欲しいユースケースっていうのは既にひとつあるんで、どっちかっていうと考えどころは<mtqueue>に乗っけるべきか別クラスにすべきかってとこ。
#実装の細かい違いでクラスが増えるのはちょっと使い辛いと思うんで、よっぽど実装の違いに意味がある場合でなければクラスひとつだけ見せて、実装の方は細かいカスタマイズで対応する方がいいかなとは思ってる。
#そうかも。
Gauche > Archives > 2011/01/07