From: Yusuke ENDOH Date: 2010-02-11T18:36:14+09:00 Subject: [ruby-dev:40393] Re: [Bug:trunk] TCPServer#gets gets stuck 遠藤です。 2010年2月11日17:35 Tanaka Akira : > 2010年2月11日17:14 Yusuke ENDOH : > >> という挙動だったのですが、以下のようにすると、このチェックは >> 抜けられることがあります (タイミングに依存しますが) 。 > > べつに落ちなければいいんですが。 > テストがあるのは、以前、落ちたからのような気がします。 いえ、問題のテストは単にカバレッジのために r16683 で私が入れたものです。 >> やるとしたら、io_read の中の READ_CHECK の直後だけでチェックしても >> だめで、buffer string に書こうとする直前で毎回チェックする必要が >> あると思いますが、IO のパフォーマンスが下がりそうなのでそこまでする >> 必要があるかどうかはわかりません。 > > EFAULT のケースだと、buffer string に書くのは read システムコールなので、 > カーネルが EFAULT で済ましてくれるというのを期待することになりますね。 > システムコールを発行する前にはメモリはちゃんとあって検査のしようがないし。 > それでは済まない OS が無いことを期待する、ということになりますかね。 そうでした。io_fread の中でチェックしてもダメですね。 EFAULT ってどのくらいあてになるんでしょうね。read 発行直後はちゃんと バッファがあったけど、ブロック中に別スレッドが free/realloc したなんて のも助けてくれるのかなあ。 実際 [ruby-dev:40391] で落ちているのがそのせいかどうかは調べてません。 > STR_TMPLOCK が使えるかなぁ。 そういえばそんなものがありましたね。それが良さそう。 >> 確かに、rubyspec の人たちも 1.8 とかで rubinius とかで固まってないの >> か不思議ですよね。今度聞いときます。 > > 確認してませんが、他にスレッドが無いのでは? > > まぁ、1.9 の場合に存在するスレッドは何かというのも確認してませんが。 TCPServer#gets の spec を単体で実行しても固まらなくて、Net::HTTP の spec とあわせて実行すると固まってました。なので、その辺のスレッドが たまたま 1.9 では生き残っているんですかね (もちろん Net::HTTP 以外の スレッドもいるかもしれない) 。 # そもそも生き残るのがおかしい？ # スレッドプールみたいなことするんでしたっけ。 -- Yusuke ENDOH