Forum: Ruby Twisted for Ruby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-09 14:36
(Received via mailing list)
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?
9358cc96c46055cd68d4a76a9aefe026?d=identicon&s=25 Daniel Harple (Guest)
on 2006-05-09 14:55
(Received via mailing list)
On May 9, 2006, at 2:34 PM, Francis Cianfrocca 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
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-09 14:58
(Received via mailing list)
On May 9, 2006, at 7:34 AM, Francis Cianfrocca 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 Gray II
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-09 15:21
(Received via mailing list)
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)?
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-09 15:30
(Received via mailing list)
On May 9, 2006, at 8:18 AM, Francis Cianfrocca 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 Gray II
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-09 15:43
(Received via mailing list)
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 Harple is thinking about the issues he
may face with distributing his new application widely, or if he's just
uncomfortable with extensions per se.
5214532353dd528a50ead7d3beb866cb?d=identicon&s=25 William Groppe (Guest)
on 2006-05-09 16:36
(Received via mailing list)
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
Ffcb418e17cac2873d611c2b8d8d891c?d=identicon&s=25 unknown (Guest)
on 2006-05-09 17:16
(Received via mailing list)
> 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 ;)
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-09 17:25
(Received via mailing list)
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.
63e5a5c299c29f41a55bb6cab0153230?d=identicon&s=25 unknown (Guest)
on 2006-05-09 19:40
(Received via mailing list)
> 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.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-09 20:08
(Received via mailing list)
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.
8c43ed7f065406bf171c0f3eb32cf615?d=identicon&s=25 Zed Shaw (Guest)
on 2006-05-12 09:09
(Received via mailing list)
On Wed, 2006-05-10 at 02:39 +0900, tsuraan@tsuraan.net 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.
733436f59b64e31c1dd78fc0d29f3cdb?d=identicon&s=25 Gyoung-Yoon Noh (Guest)
on 2006-05-12 09:31
(Received via mailing list)
On 5/12/06, Zed Shaw <zedshaw@zedshaw.com> 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?
This topic is locked and can not be replied to.