# Mongrel Pre-Release 0.3.13 -- Katana Suicide Concurrency **URL:** \ **Category:** Rails\ **Created:** [June 5, 2006, 12:10pm UTC](https://www.ruby-forum.com/t/mongrel-pre-release-0-3-13-katana-suicide-concurrency/62476 "2006-06-05T12:10:20Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Zed\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/da6949/32.png) [@Zed\_S](https://www.ruby-forum.com/u/Zed_S)\ **Post date:** [June 5, 2006, 12:10pm UTC](https://www.ruby-forum.com/t/mongrel-pre-release-0-3-13-katana-suicide-concurrency/62476/1 "2006-06-05T12:10:20Z")
We are _days_ away from the official 0.3.13 release, which will be followed quickly by 0.4 code named Enterprisey Edition 1.2. This latest pre-release update closes off the last of the annoying bugs, and adds one very nasty feature people should check out before we release. Read about Katanas below. \*\* This release doesn’t have win32 yet. That’ll be uploaded Monday. \*\* WHAT IS MONGREL It’s a web server that runs Ruby web applications. Currently supports Rails, Camping and Nitro. You can check it out at: [http://mongrel.rubyforge.org/](http://mongrel.rubyforge.org/) GETTING IT Best thing to do is this: $ gem install daemons $ gem install mongrel --source=[http://mongrel.rubyforge.org/releases/](http://mongrel.rubyforge.org/releases/) WHAT’S FIXED - Fixes a failure of -P to find PID files. - Changes the RailsHandler so that only passes GET or HEAD requests to the DirHandler for page caching. - Confirms that the new send\_file and upload to tempfile works on win32. More tests with big files uploaded on win32 are needed. - Lots of documentation on installing, with more to come. Full Apache documentation and information on writing your own snazzy handlers and filters. - François SIMOND suggested a check for allow\_concurrency and to avoid locking Rails if that’s set to true. I tried it, had to change the patch but I left it in. Read below. - Moved some of the “change to user/group” code around so that any Mongrel command can use it. - Various code clean-ups and big improvements on the unit test coverage and reporting. Check out [http://mongrel.rubyforge.org/coverage/](http://mongrel.rubyforge.org/coverage/) - Lots of thrashing and code review, not much more will come for 0.3.13 unless an obviously broken piece needs work. KATANA SUICIDE CONCURRENCY I resisted doing this, but it’s going to come down sooner or later now that François SIMOND figured it out. Mongrel was protecting the world from the allow\_concurrency “feature” but now it lets you kill yourself in obscenely horrible ways. If you set ActionController::Base.allow\_concurrency=true in your config/environments/\* then Mongrel will _NOT_ guard the Rails Dispatcher. This means that you’ll get full threaded madness thrashing your Rails controllers until they die horribly slicing themselves into tiny little bits leaving you breathless with the destruction. Mongrel will obnoxiously warn you about this, and people who try it will NOT get support from me without mad amounts of dough. If you turn this on, and your world comes crashing around your head, then I warned you. Otherwise, go ahead and give it a try and see if that improves things for you. Enjoy the release, and get those bugs in so we can fix them: [http://rubyforge.org/tracker/?atid=5145&group\_id=1306&func=browse](http://rubyforge.org/tracker/?atid=5145&group_id=1306&func=browse) And we still want documentation authors: [http://mongrel.rubyforge.org/docs/contrib.html](http://mongrel.rubyforge.org/docs/contrib.html) Pick a blank page and write it up. – Zed A. Shaw > **[Zed A. shaw](https://zedshaw.com/)** > > Personal essays and writings by Zed A. Shaw. [http://mongrel.rubyforge.org/](http://mongrel.rubyforge.org/) ---
**Author:** ![Zed\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/da6949/32.png) [@Zed\_S](https://www.ruby-forum.com/u/Zed_S)\ **Post date:** [June 5, 2006, 11:19pm UTC](https://www.ruby-forum.com/t/mongrel-pre-release-0-3-13-katana-suicide-concurrency/62476/2 "2006-06-05T23:19:48Z")
Zed S. wrote: > KATANA SUICIDE CONCURRENCY > > I resisted doing this, but it’s going to come down sooner or later now > that François SIMOND figured it out. Mongrel was protecting the world > from the allow\_concurrency “feature” but now it lets you kill yourself > in obscenely horrible ways. > > If you set ActionController::Base.allow\_concurrency=true in your > config/environments/\* then Mongrel will _NOT_ guard the Rails > Dispatcher. This means that you’ll get full threaded madness thrashing > your Rails controllers until they die horribly slicing themselves into > tiny little bits leaving you breathless with the destruction. > > Mongrel will obnoxiously warn you about this, and people who try it will > NOT get support from me without mad amounts of dough. If you turn this > on, and your world comes crashing around your head, then I warned you. > Otherwise, go ahead and give it a try and see if that improves things > for you. Hey Zed, Do you know in what ways these obscenely horrible ways might manifest themselves? I’m not at all aware of what parts of Ruby/Rails may be thread-safe and where the danger may lie. With PHP, for example, the thread-safety of various third party libraries is unknown, but supposedly core PHP is thread-safe. What benefits are there to turning on concurrency? Somewhat better performance? You 'da man! Joe ---
**Author:** ![Zed\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/da6949/32.png) [@Zed\_S](https://www.ruby-forum.com/u/Zed_S)\ **Post date:** [June 6, 2006, 12:44am UTC](https://www.ruby-forum.com/t/mongrel-pre-release-0-3-13-katana-suicide-concurrency/62476/3 "2006-06-06T00:44:48Z")
On Mon, 2006-06-05 at 23:19 +0200, Joe wrote: > Zed S. wrote: > > Hey Zed, > > Do you know in what ways these obscenely horrible ways might manifest > themselves? I’m not at all aware of what parts of Ruby/Rails may be > thread-safe and where the danger may lie. With PHP, for example, the > thread-safety of various third party libraries is unknown, but > supposedly core PHP is thread-safe. What benefits are there to turning > on concurrency? Somewhat better performance? I may list out the things that can go horribly wrong in the near future, but this is kind of a catch-22. I know of things that go wrong, but they are only in my testing and when I’ve examined the code. They’re not really bugs in rails, just usage patterns that people have which don’t work in rails (like firing up popen). What will most likely happen is people will start using this feature, they’ll have weird problems with it on that they don’t have with it off, and then we’ll start to find out what you can and can’t do. As a side note I’m looking to add a feature for 0.4 that will let you give a list of “locked URIs” to a special guard handler. This will let you lock stuff that needs it and leave the rest alone. – Zed A. Shaw > **[Zed A. shaw](https://zedshaw.com/)** > > Personal essays and writings by Zed A. Shaw. [http://mongrel.rubyforge.org/](http://mongrel.rubyforge.org/) ---
**Author:** ![Zed\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/z/da6949/32.png) [@Zed\_S](https://www.ruby-forum.com/u/Zed_S)\ **Post date:** [June 6, 2006, 1:58am UTC](https://www.ruby-forum.com/t/mongrel-pre-release-0-3-13-katana-suicide-concurrency/62476/4 "2006-06-06T01:58:55Z")
Zed S. wrote: > As a side note I’m looking to add a feature for 0.4 that will let you > give a list of “locked URIs” to a special guard handler. This will let > you lock stuff that needs it and leave the rest alone. It might be neat to allow the reverse as well – a set of thread-safe URIs that don’t lock. It might be easier to identify a handful of high-volume URIs that are known (and can be proven) to be safe, rather than presume that all but a set of URIs are safe.