[Eventmachine-talk] libevent

[Francis Cianfrocca]

On Dec 10, 2007 12:06 AM, Franki Rai <frankirai at gmail.com> wrote:

> Hello,
>
> I have been looking at the Ruby/EventMachine.  First let me say it look
> very good.  Reactor model with no threads makes for fast reliable server,
> and I have read about marvelous Twisted framework for Python and am glad to
> see something similar for Ruby.
>
> I am writing network app with Ruby threads now and it very slow, and I try
> new Ruby 1.9 with native threads that make it much slower.  Plus I'm hit
> limit with number of concurrent connections.  Ruby does not support more
> than around 1024, due to select bottleneck I think.
>
> But I have some questions before I use Ruby/EventMachine.
>
> How is the i/o multiplex handed?  I read it does epoll?  Is it custom
> library or is it something standard?
>
> I am mainly interested in bsd platform.  In the past network servers I
> write use libevent project to handle i/o.  This lets use bsd kqueue and
> linux epoll when running linux:
>
> http://monkey.org/~provos/libevent/<http://monkey.org/%7Eprovos/libevent/>
>
> So far I see no Ruby/EventMachine support for kqueue, only epoll.  I am
> trying to find way that make Ruby handle thousands of sockets with single
> process, on bsd platform.
>
> So, next question, why aren't you using libevent to handle the i/o
> multiplex already?  If so, EventMachine could support epoll for linux people
> and kqueue for bsd people, and other interfaces for other os.
>
> I was looking for libevent in Ruby and I found this:
>
> http://www.zedshaw.com/projects/ruby_event/index.html
>
> The project says it is dead due to Ruby thread.  But Ruby getting new
> thread in a few weeks, right?  Won't that fix the problem?
>
> Could you use Ruby/Event project as libevent binding for EventMachine with
> new Ruby?
>
> Thank you for answering my questions.
>



This question comes up every so often.

EM's reactor uses select(2), which is the most portable way to do it. It
also supports epoll where available. It would not be difficult to add kqueue
support to the EM reactor. It's quite similar to epoll and it probably
wouldn't be a big job.

Having programmed kqueue myself, I have to say that its performance and
scalability benefits over select(2) seem minor on the BSD platform. It's far
less of an improvement than the enormous benefit that epoll provides on
Linux. If anyone disagrees, I'm open to being convinced otherwise.

I'm just as interested in reimplementing the reactor using IOCP, which would
give a performance and scalability boost for Windows users.

As far as libevent is concerned: I don't particularly agree with the case
that libevent is any faster, more stable, or more scalable than the EM
implementation, which is based on many years of experience with high-speed
networking. And there will be an ongoing need to continue supporting Ruby
versions without native threads.

Much more importantly, however, EM is not a competitor to libevent. The
appropriate comparison is to Twisted, not to libevent. EM exists to provide
a complete platform with a standard API, for creating fast, scalable
applications. That's why it includes a library of implementations of
standard protocols, which will grow. The intention is not to enable
low-level event access. It's to provide high-level application support.

I would have no objection at all to an implementation of the EM reactor
based on libevent, provided that it passed all the existing unit tests, and
guaranteed to run all existing EM code without changes. If anyone wants to
work on this, I'll be happy to support you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071210/73c6bcc5/attachment.html