On 1/3/08, Will Green <will at hotgazpacho.com>
wrote:> >From
http://blog.codefront.net/2008/01/02/whats-new-on-edge-rails-the-pilot/
>
> A native Mongrel handler has been introduced. This is so that it can be
worked on independent of Mongrel''s release cycle (the Rails handler is
currently in the Mongrel codebase). Jeremy Kemper (bitsweat) has already made a
minor performance improvement by moving the mutex from the handler itself into
the dispatcher. This means that as Rails gets more threadsafe, the Rails team
can push the mutex further down so that it''s not a (scary) giant lock
(the existing Mongrel Rails handler has a synchronized block around
Rails'' dispatcher).
>
> Here''s the relevant Changeset URL:
http://dev.rubyonrails.org/changeset/8488
Note, this is still an experiment, not the default. You can use the
native handler on Rails trunk using script/server new_mongrel.
For starters, I imported a pared-down Rails handler and mongrel_rails''
GemPlugin commands so they''ll work with script/server directly. I
mount a DirHandler before the Rails handler and pass through missing
files rather than handling both in the Rails handler. This needs a
small DirHandler change to pass through missing files instead of
sending 404.
I think importing the GemPlugins may be overkill, but I couldn''t see
how to massage Start#run into setting up the listener how I''d like,
otherwise. I think a lot of the goodies in there, like pidfile
management and debug handling, could be extracted. It''d make building
your own mongrel runner easier.
Next steps. On the Mongrel handler side: wean Rails off the CGI
wrapper. On the Rails side: work directly with Mongrel request +
response; use a wrapper to cajole CGI::Session into compatibility;
move route recognition and sending response body out of the mutex.
jeremy