It is emulated using select() for platforms that we do not support
poll() for. It is much easier to use than rb_thread_select() and
rb_thread_fd_select() for the common case in C extensions[1].

For Linux (and eventually any other platforms where poll() works for all
select()-able files), we actually implement rb_io_poll_fd() using the
poll() system call which means it is faster for high numbered file
descriptors and does not put malloc pressure on the garbage collector.

Lastly, since IO.select() is commonly used with a single IO object
in my experience, we will try to use rb_io_poll_fd() in that case.

There is also a new testcase for io/wait since I needed to verify my
changes to ext/io/wait.c were correct.

No failures were introduced to test-all and test-rubyspec targets with
either the select() or poll()-based implementation of rb_io_poll_fd()
on my platform (Linux x86_64)

History

It is emulated using select() for platforms that we do not support
poll() for. Â It is much easier to use than rb_thread_select() and
rb_thread_fd_select() for the common case in C extensions[1].

For Linux (and eventually any other platforms where poll() works for all
select()-able files), we actually implement rb_io_poll_fd() using the
poll() system call which means it is faster for high numbered file
descriptors and does not put malloc pressure on the garbage collector.

It is emulated using select() for platforms that we do not support
poll() for. It is much easier to use than rb_thread_select() and
rb_thread_fd_select() for the common case in C extensions[1].

For Linux (and eventually any other platforms where poll() works for all
select()-able files), we actually implement rb_io_poll_fd() using the
poll() system call which means it is faster for high numbered file
descriptors and does not put malloc pressure on the garbage collector.

Concurrent connections isn't always an issue, either, but also sometimes
have many open file handles to support other tasks[1].

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.

It is emulated using select() for platforms that we do not support
poll() for. Â It is much easier to use than rb_thread_select() and
rb_thread_fd_select() for the common case in C extensions[1].

For Linux (and eventually any other platforms where poll() works for all
select()-able files), we actually implement rb_io_poll_fd() using the
poll() system call which means it is faster for high numbered file
descriptors and does not put malloc pressure on the garbage collector.

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: ). 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 ofhttp://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..

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 ofhttp://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.