# Kernel#select and threads

**URL:** <https://www.ruby-forum.com/t/kernel-select-and-threads/51016>\
**Category:** Ruby\
**Created:** [December 23, 2005, 10:46pm UTC](https://www.ruby-forum.com/t/kernel-select-and-threads/51016 "2005-12-23T22:46:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hotjuneshen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f19dbf/32.png) [@hotjuneshen](https://www.ruby-forum.com/u/hotjuneshen)\
**Post date:** [December 23, 2005, 10:46pm UTC](https://www.ruby-forum.com/t/kernel-select-and-threads/51016/1 "2005-12-23T22:46:15Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![hotjuneshen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f19dbf/32.png) [@hotjuneshen](https://www.ruby-forum.com/u/hotjuneshen)\
**Post date:** [December 23, 2005, 11:19pm UTC](https://www.ruby-forum.com/t/kernel-select-and-threads/51016/2 "2005-12-23T23:19:19Z")

</div>

From: “Jon S.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> 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

---

<div class="post-metadata">

**Author:** ![hotjuneshen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f19dbf/32.png) [@hotjuneshen](https://www.ruby-forum.com/u/hotjuneshen)\
**Post date:** [December 23, 2005, 11:28pm UTC](https://www.ruby-forum.com/t/kernel-select-and-threads/51016/3 "2005-12-23T23:28:23Z")

</div>

On 12/23/05, Bill K. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> From: “Jon S.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)
> 
> > 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?

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

---

<div class="post-metadata">

**Author:** ![hotjuneshen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/f19dbf/32.png) [@hotjuneshen](https://www.ruby-forum.com/u/hotjuneshen)\
**Post date:** [December 24, 2005, 1:19am UTC](https://www.ruby-forum.com/t/kernel-select-and-threads/51016/4 "2005-12-24T01:19:40Z")

</div>

From: “Jon S.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> > 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](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](http://glu.ttono.us/articles/2005/10/14/yarv-progress-report)

Regards,

Bill