On Jan 18, 2011, at 6:50 PM, ae wrote: > > On Jan 18, 9:17 pm, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Jan 18, 2011, at 5:41 PM, ae wrote: >> >> >> >>> On Jan 18, 11:22 am, Jonathan Lundell <jlund...@pobox.com> wrote: >> >>>> When you say "anyone associated with the thread", do you mean other >>>> requests using some shared, locked resource (like the session)? Or >>>> something else? >> >>> Browser sessions seem to get associated to a thread. As long as that >>> thread is busy the user won't (and anyone else who's session is >>> assocated to that thread won't) be able to do anything else. This >>> mostly seems like a security precaution and is good. >> >> Each request runs in its own thread. Users don't share sessions, so session >> serialization won't block other users. Database serialization could, though. >> >> On the whole, I think you're better off using JavaScript to make this kind >> of thing asynchronous. Better user experience, too. > > Yeah. I didn't ever think that users share sessions, but I believe > that a browser cookie is set and that cookie is associated to a > thread. (one thread, many sessions).
No, a cookie is associated with a session. For all practical purposes, each request gets its own thread (in practice, threads are recycled through a thread pool, but that's just for efficiency). Threads themselves don't retain any meaningful identity from one request to the next. > When a thread is busy for a > while, all users associated to that thread will block on that thread. When a request is busy for a while, all other requests with the same session will block on that session (unless the busy thread does a session.forget(response)). > (note that I'm using an old version that uses CherryPy, but I would be > surprised if it's different with Rocket) > > Try creating a file like this default.py: > > > def blockme(): > import time > time.sleep(30) > > > def sayjunk(): > return "<html><head><title>Junk</title></head><body>junk</body></ > html>" > > > > Then hit the blockme function from your browser and before the end of > that 30 seconds see if you can access sayjunk. > > I have a few controllers that occasionally take longer than expected. > When that happens I have reports of multiple users not being able to > access the application for until they 1) wait a while or 2) restart > their browser. > > Again, I just wanted to see if anyone had thought of a simpler > solution than I did. > > --Todd >
