Your code does not block the server. Only blocks the session
associated to your browser to guarantee integrity of the data in your
session. If you know that the block function takes time and it does
not need to save session, you can do:
def blockme():
session.forget()
import time
time.sleep(30)
def sayjunk():
return "<html><head><title>Junk</title></head><body>junk</body></
html>"
On Jan 18, 8:50 pm, ae <ae88...@gmail.com> 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). When a thread is busy for a
> while, all users associated to that thread will block on that thread.
> (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
