On Jan 19, 2011, at 6:50 AM, ae wrote: > > > > On Jan 19, 9:17 am, Anthony <abasta...@gmail.com> wrote: >> On Wednesday, January 19, 2011 8:18:25 AM UTC-5, ae wrote: >> >>> I have lots of users and when one thread takes a long time, some users >>> can keep accessing controller functions and some can't. Once the long- >>> running controller finishes, everyone can access stuff again. >> >> Are you saying that when user A hits a long-running controller (action), >> that sometimes blocks user B (who is presumably using a different machine) >> from accessing the application? Is this just a thread starvation issue? I >> assume user B wouldn't be affected by user A unless there just aren't any >> available threads left to service B's request, no? > > Possibly. If you have many threads, then B is unlikely to be assigned > to the same thread as A and the behavior won't be exhibited. > > Configure web2py with just two threads and open a few browsers using > different profiles (they each have to have unique cookies). They can > be on different hosts or not (My office-mate and I each have a desktop > and a laptop--we tested this together). > > As for thread starvation, I'd say no. The host running web2py is an 8- > core machine that's mostly idle. I've also tested this on my desktop > (4-core) which was also mostly idle. Also, the 'blocking' in the long > running function is just a call to sleep() and in the production > environment it's a connections to other hosts that block; they return > small (<1k) strings. Lastly, if it were thread starvation, then I > would expect that no user could do anything. For users who /can/ > access the app, performance is normal. > > It's easy to test this (but once more: Rocket might be different). >
When a request is received, a thread is created (or recycled from a thread pool) to handle it. That thread is dedicated to that request for its entire life cycle, and is destroyed or returned to the pool afterward. The request is associated with its session by means of a cookie. The session is locked for the duration of the request (or until you call session.forget(response) to release the lock), so any new request with the same cookie/session will block until the session is released.
