Io-reactor 1.0.4

Version 1.0.4 of IO-Reactor has been released.

IO-Reactor is a pure-Ruby implementation of an asynchronous multiplexed
IO
Reactor which is based on the Reactor design pattern found in
Pattern-Oriented
Software Architecture, Volume 2: Patterns for Concurrent and Networked
Objects
.
It allows a single thread to demultiplex and dispatch events from one or
more IO
objects to the appropriate handler.

== Project Page

http://deveiate.org/projects/IO-Reactor/

== Installation

Via gems:

$ sudo gem install io-reactor

or from source:

$ wget http://deveiate.org/code/io-reactor-1.0.4.tar.gz
$ tar -xzvf io-reactor-1.0.4.tar.gz
$ cd io-reactor-1.0.4
$ sudo rake install

== Changes

On Tue, Aug 19, 2008 at 6:37 PM, [email protected] wrote:

Version 1.0.4 of IO-Reactor has been released.

IO-Reactor is a pure-Ruby implementation of an asynchronous multiplexed IO
Reactor

Just curious, what motivated you to write this? I can’t imagine it
performs
very well (is it using IO.select?) and there are already two C-based
Reactor
libraries available for Ruby that I know of: EventMachine and Rev.

EventMachine also has pure Ruby and JRuby versions available.

And as an aside: I’m the author of Rev.

Tony A. wrote:

Version 1.0.4 of IO-Reactor has been released.

IO-Reactor is a pure-Ruby implementation of an asynchronous
multiplexed IO Reactor

Just curious, what motivated you to write this?

I needed a way to multiplex the IO from many sockets, and found the
Reactor pattern much more usable than doing the usual hoop-jumping
associated with using select().

I can’t imagine it performs very well (is it using IO.select?) […]

If in your imagination IO.select never performs adequately to the task
at hand, then I guess it can’t, as it does indeed use IO.select. I have
not found your imagined performance problems to be true in reality for
my applications, however.

[…] and there are already two C-based Reactor libraries available
for Ruby that I know of: EventMachine and Rev.

While there are now (at least) two C-based “Reactor” libraries, there
was nothing of the kind at least on the RAA when I wrote the first
version (back when it was Ruby-Poll).

I certainly had no intention of impugning your hard work (or Francis’s)
by releasing a bugfix for a library I wrote that does a similar thing a
different way. I just have other code that depends on IO-Reactor, and
wanted to (belatedly) apply patches that other people were kind enough
to send me in case other people do too.

EventMachine also has pure Ruby and JRuby versions available.

Good to know; I’ll keep it in mind should I ever feel like IO-Reactor
isn’t addressing my needs anymore.

And as an aside: I’m the author of Rev.

Okay. Rev’s API looks very clean and pleasantly Rubyish in its idiom. I
look forward to using it for something.

I was very interested in libevent when I first heard of it, but after
hearing about the struggles Zed S. had with his Ruby/Event library, I
guess I dismissed it as a possibility for doing event-based IO in a Ruby
program with multiple threads. I’ll be interested to see how you have
solved that problem when I have time to study Rev’s source a little more
and do some experimentation.

On Aug 19, 9:18 pm, “Tony A.” [email protected] wrote:

On Tue, Aug 19, 2008 at 6:37 PM, [email protected] wrote:

Version 1.0.4 of IO-Reactor has been released.

IO-Reactor is a pure-Ruby implementation of an asynchronous multiplexed IO
Reactor

Just curious, what motivated you to write this? I can’t imagine it performs
very well (is it using IO.select?) and there are already two C-based Reactor
libraries available for Ruby that I know of: EventMachine and Rev.

Michael’s lib has been around for much longer than these others. I
even distributed it with Facets for a while. I’m happy to see it has
it’s own solid project now.

T.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs