On Aug 25, 4:15 pm, Aaron Smith <beingthexempl... / gmail.com> wrote:
> 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 viahttp://www.ruby-forum.com/.

The 'Rails gateway' is specific to a mongrel process - each process
has their own. Each process will handle one Rails thread.
For that reason you don't have to worry about shared variables.
--Dave