From: Toby DiPasquale <toby@...>
Date: 2006-01-24T11:27:48+09:00
Subject: Re: Mongrel 0.1.1 -- A Fast Ruby Web Server (It Works Now, M

Zed Shaw wrote:
> You're going to laugh but right now it's down to a bit of Ruby and a
> nifty C extension.  Seriously.  No need yet of much more than some
> threads that crank on output, a parser (in C) that makes a hash, and
> a way to quickly lookup URI mappings.  The rest is done with handlers
> that process the result of this.  

That's a PATRICIA trie for URL lookup, a finite state machine compiled 
Ragel->C->binary for HTTP protocol parsing and an implicit use of 
select(2) (via Thread), for the even-more-curious out there ;) (first 
hit on Google for "Ragel" will tell you what you need to know about 
that)

> It may get a bit larger than this,
> but this core will probably be more than enough to at least service
> basic requests.  I'm currently testing out a way to drop the threads
> in favor of IO.select, but it looks like that messes with threads in
> some weird ways.

Ok, so here's where I fell off your train. On your Ruby/Event page, you 
said that you killed the project b/c Ruby's Thread class multiplexes via 
the use of select(2), which undermines libevent's ability to effectively 
manage events (which I had discovered while writing some extensions a 
while back and thought "how unfortunate"). But I have some questions 
about the above:

1. As above, the Thread class uses select(2) (or poll(2)) internally; 
what would be the difference in using IO::select explicitly besides more 
code to write to manage it all?

2. What are these "weird ways" you keep referring to? I got the 
select-hogging-the-event-party thing, but what else?

I am interested b/c I am currently trying to write a microthreading 
library for Ruby based on some of the more performing event multiplexing 
techniques (kqueue, port_create, epoll, etc) so I can use it for other 
stuff I want to write (^_^)

> Once I figure out all the nooks and crannies of the thing then I'll
> do a more formal design, but even then it's going to be ruthlessly
> simplistic.

Simple is good, m'kay? ;-) Great show in any case! I know I'll be using 
this for my next internal Rails app.

-- 
Posted via http://www.ruby-forum.com/.