From: Gennady Date: 2002-12-14T06:08:48+09:00 Subject: Re: TCP Server ----- Original Message ----- From: "Bill Kelly" To: "ruby-talk ML" Sent: Friday, December 13, 2002 12:54 PM Subject: Re: TCP Server > > From: "Idan Sofer" > > Bill Kelly wrote: > > > > >I prefer to use select() than threads, for a couple reasons, in Ruby. > > >My sense is that, since the whole process is blocked (all your threads) > > >if one of your IO calls stalls (in any thread), then you have to find > > >a way to do non-blocking IO whether you're using threads or not. And I > > >personally find select() to be sufficient to the task without bothering > > >with threads. (It may just be personal opinion, or preference. :) > > > > > > > > I have not encountered such situation when using threads. > > > > My application have a set of worker threads, which either serve a > > client, waiting on a Mutex protecting accept(), or waiting at accept(), > > so there is always one thread waiting on accept(), and the application > > does not block. > > > > I suppose Ruby does some tricks to overcome the blocking. > > Whoa. Interesting. Well, my apologies if my post was incorrect. > I've read accounts on ruby-talk in the past of the whole process > (all Ruby-threads) being blocked during IO. I had taken this to What might be ment is that when you write your own C extention and you call a C function from Ruby, all Ruby threads are blocked until the function returns. So if you block on IO operation (say, calling read()) in that function, no Ruby threads will have a chance to execute. However if you do IO via pure Ruby API, everything works fine (threads are not blocked). > mean this was the general case, rather than some specific exception > being discussed. > > Hmm, it's nice when Ruby is smarter than me (seems to keep happening :) > > In my particular application, avoiding threads still seems convenient, > as I can disregard reentrancy issues. > > Thanks, > > Bill > > > > > >