So my weak brain is trying to put this all together. Here's what I make 
of it and how it answers my questions. Correct me if  I'm wrong.

>The Rails mongrel handler has a mutex that locks the action within it to 
>a single thread of execution at a time.  So, if 10 requests come in at the
>same time, Mongrel will create 10 threads of execution for those 10
>requests, but when execution flow reaches the Rails handler, each thread
>will stand in line at the mutex gate and proceed through it in single
>file."

When relying on Rails, the rails handler has a mutex in it so that only 
one thread will ever go through the rails handler until it's complete 
and then let's the next thread through for processing? So that would 
tell me that if my app is relying on Rails, that I don't need to worry 
about access to shared variables, such as static variables? As it isn't 
truly executing multiple threads at once.

That does lead me to another question if using multiple Mongrel 
processes. Multiple processes allow mongrel to receive more requests 
thus creating more threads, but the Rails gateway is still opening the 
gate for one thread at a time?

Also all this discussion makes me think of another question. I'm using a 
dispatcher in my application. found 
here(http://derrick.pallas.us/ruby-cgi/). For someone who's reading the 
code and knows a lot about mutex, are there any things that stand out to 
someone as being a bad solution with this dispatcher? keeping in mind 
multiple requests at once and possible shared resource headaches? I'm 
just trying to get a feel for what I need to look into to make this 
dispatcher better and avoid shared resource collisions.

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