kernel#select and threads

J

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.

If select isn't using kernel threads, what the strategy in ruby to
leave a select outstanding while other things get done?
 
B

Bill Kelly

From: "Jon Smirl said:
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.

The catch is that some system calls, like write() or send() may block
the whole native process thread, causing all of ruby's green threads
to block. In practice you can usually avoid this on Unix systems
with:

sock.fcntl(Fcntl::F_SETFL, sock.fcntl(Fcntl::F_GETFL) | Fcntl::O_NONBLOCK)

On Unix systems, I think the NONBLOCK setting will work on file and
pipe I/O as well as sockets.

On Windows, i don't think there's any way to do non-blocking I/O
from ruby, yet.


Regards,

Bill
 
J

Jon Smirl

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?

Any future plans for ruby to use kernel threads instead of green ones?
 
B

Bill Kelly

From: "Jon Smirl said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top