[Nitro] Nitro on Apache

[s.ross]

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.

Hmmmm?


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.
>
>