Re: Stateful I/O interface

I'm looking primarily for scalability improvements in terms of handling
higher numbers of concurrent connections.  It's definitely something where
any implementation would need to be benchmarked to determine if it's
actually useful.

-- 
Tony Arcieri
ClickCaster, Inc.
[e-mail]

On 2/22/07, Francis Cianfrocca <[e-mail]> wrote:
>
> On 2/22/07, Tony Arcieri <[e-mail]> wrote:
> >
> >
> > I'm thinking of putting together a quick patch would provide basic epoll
> > support through my suggested interface.  Would that be helpful in evaluating
> > this idea?  I could also write a small benchmarking program to compare
> > Kernel#select performance to a stateful interface.
> >
>
>
> One question for you (I may have already asked you this, if so, I
> apologize): what are your success metrics for an epoll implementation? Why
> do you actually need it? Are you looking for performance improvements, an
> improvement in scalability (breaking the 1024-descriptor limit), or
> something else. When I did a (non-published) epoll version of EventMachine,
> I was surprised to find that it wasn't measurably faster than the
> select-based implementation. I think this is because the performance profile
> of an EM program is so dominated by the ruby glue and by user-supplied ruby
> code that making the raw I/O faster just won't be that noticeable.
>
>