From: Francis Cianfrocca <garbagecat10@...>
Date: 2007-05-30T06:16:21+09:00
Subject: Re: [ANN] EventMachine 0.7.2 has been released

------=_Part_60549_32810224.1180473361035
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/29/07, tsuraan <tsuraan@gmail.com> wrote:
>
>  Ok, I have one question (I have the same question for Twisted, but
> haven't
> asked them about it...): why not use libevent?  It seems much more
> developer-friendly than having to write your own implementations of epoll,
> kqueue, poll, select, etc.  Why isn't it more widely used?
>



I can't speak for Twisted. As far as Ruby is concerned, there is a problem
with libevent and libraries like it, in that it's a challenge to integrate
with Ruby because of how Ruby's thread scheduler works. The problem was easy
enough to work around in EM because we wrote the whole stack.

A minor issue is that libevent is a very complex library full of features,
with a large API intended for use by low-level programmers. That's entirely
suitable for a certain class of tasks, but EM is aimed at the other end of
the scale: it seeks to wrap up the complexity of network programming and
hiding it behind as simple and high-level an API as possible.

Even more to the point, the goal of EM is to provide a complete framework
for highly-scalable, fast programs that are network-aware. Just handling
descriptor-level I/O is a small part of the charter. You'll soon start
seeing releases of full-featured handlers for a variety of standard
protocols, as well as higher-level support for applications that make use of
those protocols.

Speaking for myself personally, libevent is a first-rate piece of work. But
I've been writing network programs for quite a few years now, and I find
using my own knowledge to be more developer-friendly than using libevent
;-).

------=_Part_60549_32810224.1180473361035--