Re: Stateful I/O interface

On 2/22/07, Paul Brannan <[e-mail]> wrote:
>
> For now, I think this is best done as a library.


At present, as far as I'm aware even under YARV native extensions are bound
to Ruby's scheduling quantum.  For the time being the blocking calls also
need looping timeout calculation similar to do_select in thread.c.  It seems
to me that the thread scheduler and I/O scheduler should be highly aware of
each other, and that simply isn't possible in an extension.  Whoever
implements the extension will inevitably end up copying code out of
thread.cwhich may or may not change.

The reactor pattern is a well-accepted pattern for implementing such a
> mechanism.  There is a
> reactor library for ruby, but it needs to have additional I/O
> multiplexing mechanisms implemented.


And that is precisely the problem.  The interface I'm suggesting is intended
to be the simplest way possible to bring epoll and kqueue like system calls
into Ruby, where they could be used by people implementing something like
the Reactor pattern or EventMachine.  It's not intended to put a pretty face
on it (just as Kernel#select wasn't) but to minimize the amount of C and
Ruby glue to access the underlying system calls.

I would like to see a way to pick a different I/O multiplexing mechanism
> at runtime.  IMO the problem isn't what Kernel#select does (you don't
> have to use it), but what rb_thread_select does (you aren't given a
> choice here).


Kernel#select scales O(n) due to the need for the kernel to process the list
of file descriptors to monitor with each system call.  With stateful
interfaces like epoll and kqueue, the scalability is O(1) as the kernel does
its event reporting on-the-fly and returns all events to the queue where
they can be retrieved via a system call.

Integrating ruby's event loop with a library that uses a
> different mechanism requires that the library be able to use ruby's I/O
> multiplexing system, but may not be possible or desirable, especially if
> ruby is embedded in an application.


Unless I'm misunderstanding the way rb_thread_select and
rb_thread_wait_fd_rw are implemented (both tie into a single underlying
do_select call), a different mechanism could operate alongside select calls
provided it only blocked for the scheduler quantum.  This way calls to
select and a stateful event monitoring interface could alternate within
Ruby's event loop, allowing both to run (effectively) simultaneously.

Implementing the rb_thread_select and rb_thread_wait_fd_rw calls with a
stateful interface like epoll or kqueue would probably not be beneficial
because the set of monitored file descriptors must be processed with each
call anyway (and are subject to change).  I'd suggest these interfaces
remain select() based for the time being (as they use select's semantics
anyway) although they could potentially be optimized with poll(), although
benchmarking would be required to determine if a poll()-based implementation
were actually advantageous.

epoll and kqueue both provide extremely powerful interfaces which could
serve as the central underlying system call behind an event loop, however in
the case of Ruby this would require a dramatic rearchitecting of the way the
event loop functions.  That's why I'm suggesting something dramatically
simpler: providing a simple bridge between these system calls and Ruby which
can run within the existing event system.

I'm thinking of putting together a quick patch would provide basic epoll
support through my suggested interface.  Would that be helpful in evaluating
this idea?  I could also write a small benchmarking program to compare
Kernel#select performance to a stateful interface.

It's been suggested that Ruby use WaitForMultipleObjects on win32 (see
> [ruby-talk:47186]).  There are pros and cons to doing this, but I'm not
> qualified to enumerate them.


Either of these are going to be suboptimal on Windows due to the intrinsic
64 object limit on these calls.  The proper solution to this on Windows
would be to move to an event completion-based interface which could be used
in conjunction with Win32 I/O completion ports, however the I/O completion
model has inherent problems as well, particularly when implementing buffered
readers.

IOCP certainly isn't suitable for implementing either rb_thread_select or
rb_thread_wait_fd_rw.

-- 
Tony Arcieri
ClickCaster, Inc.
[e-mail]