From: Brian Candler <B.Candler@...>
Date: 2002-11-12T20:11:31+09:00
Subject: Re: Threading in I/O libraries

On Tue, Nov 12, 2002 at 04:21:03AM +0900, Yohanes Santoso wrote:
> > I'd like to ask: how integrated is threading in Ruby's I/O libraries?
> > 
> > In particular,
> > 
> > (1) if I do a read from a socket, will Ruby call select() first to ensure
> > that there is data available (to prevent blocking), or do I have to do that
> > myself?
> 
> Determine existence of data by yourself to prevent blocking on that thread.

That's not quite what I meant. It doesn't matter if that one thread blocks -
that's actually what I want.

However, if IO#read simply called the Unix read() function, then the entire
Ruby interpreter would be locked out (including all other threads).

So what I was asking is, does IO#read actually do something else? For
example a kernel#select followed by a read? Then, does the same apply to all
the I/O functions, like sysread for example?

> > (2) if I call select() in one thread and no data is available, will this
> > block the whole Ruby interpreter? Or is it clever: combining all the
> > select()s from multiple threads and waking them up as their FDs become
> > ready?
> 
> IAQS, select() will block only that thread. Ruby's threading is
> implemented using signal (VALRM?)

Ah. SIGIO perhaps?

> In general, the I/O handling is pretty nice in Ruby. I/O blocking
> occuring in one thread does not affect other threads.

That's cool.

Thanks,

Brian.