From: Bill Kelly Date: 2005-12-24T09:18:44+09:00 Subject: Re: kernel#select and threads From: "Jon Smirl" > > On 12/23/05, Bill Kelly wrote: > > From: "Jon Smirl" > > > Does calling kernel#select stop all ruby threads while it is waiting > > > or does the interpreter run the select on a different kernel thread? > > > By running the select on another kernel thread other ruby threads > > > could run while this call is blocked. > > > > Ruby multiplexes it behind the scenes, using just one native thread. > > If one ruby thread does a select and would block, ruby will switch > > to a different ruby thread. If all ruby threads wanted to select > > and block, ruby's scheduler would really do a blocking select. > > How does this work when the ruby threads are all idle? Something like: > if ruby threads waiting, select with zero timeout; if no ruby threads > waiting select with 100ms timeout? Then it keeps reissuing selects to > simulate my higher level timeout I set on kernel#select? If *all* ruby threads go to sleep forever, ruby's scheduler will abort with a "deadlock" error. Otherwise, I believe it just select's with the shortest timeout appropriate. You can see the code for rb_thread_schedule() in eval.c online: http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/eval.c?rev=1.616.2.78 (Rev 1.616.2.78 is ruby 1.8.2 version) > Any future plans for ruby to use kernel threads instead of green ones? Yes, check out the "Native Thread Support" section of the YARV Progress Report: http://glu.ttono.us/articles/2005/10/14/yarv-progress-report Regards, Bill