Jon Smirl
12/23/2005 10:28:00 PM
On 12/23/05, Bill Kelly <billk@cts.com> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
> > 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?
> 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
>
>
>
--
Jon Smirl
jonsmirl@gmail.com