KOSAKI Motohiro <kosaki.motohiro / gmail.com> wrote:
<snip>
Thanks again for your reply and support :>

> 2011/3/29 Eric Wong <normalperson / yhbt.net>:
> > I mainly think select() is a horrible interface and having extension
> > authors to deal with HAVE_RB_FD_INIT and remembering rb_fd_term() is
> > dangerous. Small bits of pressure from Rubyists can hopefully steer
> > other OSes towards better poll() support.
> 
> I'm sorry. I haven't catch this. can you please explain more detail?

rb_fd_init() uses malloc() to create fdsets instead of traditional stack
allocation.  This also requires using rb_fd_term() to free() memory, so
rb_ensure() must be used[1].   Often this is for waiting on a single fd,
so the rb_io_poll_fd() interface is better for extension authors all
around even if it internally uses select().

As for poll() support, Evan Phoenix pointed out poll() doesn't work on
OS X with ttys/pipes (ref: [ruby-core:35529]).  I don't know about other
kernels.  Ideally, poll() should work everywhere select() does (and
select() should be deprecated).  I would like to encourage other OSes to
get where Linux is (or get more people using Linux :).

On a related note:

  Ruby also still needlessly checks for read/writability with select()[2]
  even though though we have support for blocking regions.   I think
  that is safe to remove if we check return values with
  rb_io_wait_{read,writ}able().  One part of
  http://redmine.ruby-lang.org/issues/4535 does exactly this but I have
  another patch to kill more unnecessary select() calls that aren't
  bugs, just extra code/syscalls.


[1] though from reading through do_select() in thread.c, I don't think
do_select() can raise..

[2] via rb_thread_wait_fd()/rb_thread_fd_writable()

-- 
Eric Wong