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 2006-05-09 16:36
on 2006-05-09 16:55
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 2006-05-09 16:58
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
on 2006-05-09 17:21
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)?
on 2006-05-09 17:30
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
on 2006-05-09 17:43
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 2006-05-09 18:36
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
on 2006-05-09 19:16
> 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 ;)
on 2006-05-09 19:25
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.
on 2006-05-09 21:40
> 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.
on 2006-05-09 22:08
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 2006-05-12 11:09
On Wed, 2006-05-10 at 02:39 +0900, email@example.com 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 2006-05-12 11:31
On 5/12/06, Zed S. <firstname.lastname@example.org> 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?