All:
On another thread ("Considering Ruby for a Network Application), Giles
Bowkett made reference to the “Twisted” application framework available
to
Python programmers, and that got me thinking. How many of you are
familiar
with Twisted or have used it to develop an application? I’d like to know
if
there is any interest among Rubyists in having such a well-elaborated
event-handling framework for Ruby.
I recently released a single-threaded reactor-based library called
“EventMachine,” which could form the basis for a more complete
framework.
This codebase is the result of a lot of experience with high-performance
network servers, and it supports TCP, UDP, SSL/TLS and timer events now.
To
bring it up to the next level, we’d need to add support for other kinds
of
events, like keyboard, disk i/o, IPC, and programmatically-generated
pseudo-events. We’d probably also want a thread-pool manager. It might
also
be fun to layer Drb on top of EventMachine.
For protocol support, Twisted uses a plugin model. EventMachine uses a
more
Ruby-esque mixin model, and we have already used it to build an HTTP/S
server (“monorail,” released on Rubyforge), an LDAP server (“Peregrine,”
not
yet publicly released), a SIP proxy and an SMTP server (not released
publicly yet). Other things like RADIUS, SOAP/REST, instant messaging
are
also possible.
Comments? Complaints? Wish-lists? Anyone wanna help?
On May 9, 2006, at 2:34 PM, Francis C. wrote:
I recently released a single-threaded reactor-based library called
“EventMachine,” which could form the basis for a more complete
framework.
[…]
Comments? Complaints? Wish-lists? Anyone wanna help?
I think you will find a lot of interest, but IMO it would be best for
the lib to be wrote in Ruby instead of C++.
This recent interest in event-driven networking is an odd
coincidence, since I am currently writing a networking app, and I was
going to roll my own base for it. I looked at using EventMachine, but
I have decided not to because it requires a C++ compiler.
– Daniel
On May 9, 2006, at 7:34 AM, Francis C. wrote:
I’d like to know if there is any interest among Rubyists in having
such a well-elaborated
event-handling framework for Ruby.
My opinion is that this would make you a lot of new friends. 
James Edward G. II
I appreciate your comment. We did EventMachine in C++ for some
particular
reasons: Performance and scalability of course, but also we learned (the
hard way) that Ruby’s implementations of network i/o are not as
well-behaved
as we’d hoped. (So what does that borderline-provocative statement
actually
mean :-)? I think that Ruby attempts to be very good about wrapping up
the
details, so it handles normal cases very well, but there are some subtle
edge conditions that come up in production network applications that
Ruby
doesn’t expose. And they cause trouble. I’m used to writing
single-process,
single-thread network servers that can handle thousands of users, and
run
for months or years without restarting or throwing exceptions.)
All that said, I recognize the pain-in-the-neck resulting from having to
compile the extension. Does it make you any more comfortable if we
release
binary versions for all the various platforms? Another thing we could do
easily enough is backport the code from C++ to C. Would that help? And
finally, are you writing for Windows, Mac or Solaris (where compilers
are
generally not available) or Linux or BSD (where they often are)?
Understood, but I was thinking about the masses of OSX machines out
there not running on programmer’s desks, so they haven’t installed the
dev package. The same is true for Solaris (most definitely a Unix
flavor!), since most of those machines have nothing but the cruddy
little /usr/ccs/cc compiler or nothing at all. I asked the question
because I’m wondering if Daniel H. is thinking about the issues he
may face with distributing his new application widely, or if he’s just
uncomfortable with extensions per se.
On May 9, 2006, at 8:18 AM, Francis C. wrote:
And finally, are you writing for Windows, Mac or Solaris (where
compilers are
generally not available)…
Just a minor correction here: Mac OS X is a Unix flavor so compilers
are very available for it. I doubt Ruby ran on earlier versions of
the Mac OS where that was not true.
James Edward G. II
C++ or not, I think this would be an excellent addition to the
ruby-verse. I have at least two projects that could use this kind of
framework. I’d be happy to test the ruby/os x side of things.
-Will
C++ or not, I think this would be an excellent addition to the
ruby-verse. I have at least two projects that could use this kind of
framework. I’d be happy to test the ruby/os x side of things.
Would it be terrifically difficult to have both a c++ implementation,
and a pure Ruby one? 
You’d guess the Ruby implementation would be
about a 10th the size anyway
LOL! Considering we’re doing essentially a completely parallel rewrite
of
EventMachine for Windows (using I/O completion ports), and will
probably do
one for Linux 2.6 kernels (using epoll), it wouldn’t take much to do
one in
Is libevent an option for this? I don’t really know much about it, but
it seems to wrap poll/epoll type things pretty nicely.
LOL! Considering we’re doing essentially a completely parallel rewrite
of
EventMachine for Windows (using I/O completion ports), and will probably
do
one for Linux 2.6 kernels (using epoll), it wouldn’t take much to do one
in
pure Ruby, but it might be light on features. Certainly would be light
on
performance.
I believe this has been tried and didn’t work all that well. Among
other things, there were issues interacting with Ruby threads. With
EventMachine, we set out from the beginning to do something that would
be Ruby-esque.
On Wed, 2006-05-10 at 02:39 +0900, [email protected] wrote:
Already did that a long time ago.
http://www.zedshaw.com/projects/ruby_event/ and it worked OK. Even
implemented the original SCGI Rails Runner using it as well as a telnet
processor. Problem came from a clash with select in Ruby and libevent.
Francis solved it by using a pthread to run the select separately from
the ruby interpreter. Something similar could be done with Ruby/Event
but most of my time is spent on Mongrel these days.
Incidentally, Ruby is apparently picking up libevent based events rather
than select for it’s threads so a lot of this might be totally useless
in a year, or two, or ten, or whenever.
On 5/12/06, Zed S. [email protected] wrote:
Incidentally, Ruby is apparently picking up libevent based events rather
than select for it’s threads so a lot of this might be totally useless
in a year, or two, or ten, or whenever.
Is it true? If so, that means future ruby implementation would
have dependency with libevent?