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

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

On 5/30/07, tsuraan <tsuraan@gmail.com> wrote:
>
> 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?


The EM reactor core currently includes an I/O processor and a timer
processor. We'll be adding a signal reactor very shortly. I started adding a
file I/O processor, but in this age of really advanced kernel-VM and disk
controllers, I'm not sure it's worth it. I'm undecided whether we should add
keyboard and mouse events, not because that's a bad idea, but because
Twisted did it and they messed up a lot of things when they did. Then they
took their multiple implementations of the same things and started calling
them features. ;-)

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


Give EM a try. I think you'll find that, like Ruby itself, it takes care of
a lot of the low-level stuff that other tools force you to think about, and
lets you just get on with coding your application.

------=_Part_3910_7047983.1180538888119--