From: tsuraan <tsuraan@...>
Date: 2007-05-31T00:06:27+09:00
Subject: Re: [ANN] EventMachine 0.7.2 has been released

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

> 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.


Ok, that makes sense.

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.


Those will still run on a select (or epoll or kqueue) based core though,
right?  Or are you going to make use of non-fd events such as signals?

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
> ;-).
>

I was just thinking that libevent looks like a really nice way to get a
high-performance cross-platform mainloop.  Twisted has a dozen different
"reactors" to handle poll, select, kqueue, epoll,
whatever-the-heck-windows-uses, etc.  I would think riding on top of a
library like libevent as an abstraction above those would be nice.  I've
never used libevent though, and from what I've read on its API, it does look
like you have to write your entire program on around it; it hadn't occurred
to me that integration with it would be made difficult by the fact that Ruby
isn't written around libevent.

------=_Part_5898_33283129.1180537544589--