[Nitro] Nitro on Apache
cwdinfo at gmail.com
Wed Oct 3 17:34:43 EDT 2007
First to Kirk: Sorry about the attribution -- my mistake. Second,
this is more a general comment on the desirability and cost/benefit
of using threads in short-duration processes such as request/response
cycles. The cost of tracking down and fixing a concurrency bug may be
higher than adding a mongrel or whatever. If swiftiply solves some or
much of this problem, I'll be very happy. In the meantime, the cheap
way to remove blocking is add servers in separate processes.
Rob, if Rails is any example, features and stability will trump
concurrency for a long time. Certainly, threading is worth keeping on
the radar, but then you have to open the discussion of whether green
threads really do what you want and which of the next-generation Ruby
engines are likely to succeed in providing an efficient threading
model -- efficient enough to make thread-safety a priority.
I believe one philosophy that typically works is the "sin no more"
philosophy. If you know you didn't get concurrency right in the first
place, at least don't knowingly create new problems.
On Oct 3, 2007, at 1:08 PM, Robert Mela wrote:
> For sure -- it'd be labor intensive and tedious to take a legacy
> framework with all its associated plugins from disparate sources
> and make it thread-safe. You'd have to make the default mode
> single-threaded and allow a year or two for plugins and new
> development to catch up.
> There are actually very few cases where a framework user would need
> to consider concurrency. Most of the shared resources are things
> like session stores, database connections -- and all that's taken
> care of by the framework. Presumably a developer advanced enough
> to create a shared resource is also someone who has a clue as to
> what needs to be done.
More information about the Nitro-general