is web.py utils.ThreadedDict really thread safe?

[Alva Yi]

Yes, actually it is! It's thread safe, because it binds variable to the current thread, but with CherryPy, I can say not. CherryPy WSGIServer use a thread pool,
that means it will recruit some thread at start time, and later use these threads for the requests instead of create new ones.
In web.py ThreadedDict, it doesn't clearn the variable it bound to.
it can be a problem, for example, sessions.
Am I wrong? I tried a whole day to debug the session problem, and I found that, if I run out of the thread in the threadpool,
then each thread is 'dirty', and UserAuthentication processor don't work anymore. and I think it's caused by the thread pool of CherryPy

[Aaron Swartz]

Yes, ThreadedDict doesn't clear its dictionaries when a request is
done, because it doesn't know anything about requests. web.ctx, on the
other hand, does get cleared at the end of requests.

[Alva Yi]

Thanks for your reply. I just have read CherryPy Server's source code, and I even want to add a row to clear the dictionary after the request even it is not a good idea to hack it like this.
And as you remained, how can I use session? bound it to web.ctx? I just didn't figure it out.
It's seems that all the code examples of session usage have problem like I said, after a few requests, the threads become 'dirty'.
can you give me another example? thank you.

2009/1/5 Aaron Swartz <m...@aaronsw.com>

[Alva Yi]

here is the code a picked from application.py
may be it's a bug here, it is the return expression that stoped the clean work!


    def _cleanup_threadlocal(self):
        return  <-------------------LOOKES LIKE A BUG
        #@@@
        # Since the CherryPy Webserver uses thread pool, the thread-local state is never cleared.
        # This interferes with the other requests.
        # clearing the thread-local storage to avoid that.
        # see utils.ThreadedDict for details
        import threading
        t = threading.currentThread()
        if hasattr(t, '_d'):
            del t._d

2009/1/5 Alva Yi <alv...@gmail.com>

[Alva Yi]

it's provied to be a BUG here. I think I fixed this problem.
this bug cann't be fixed by remove the return exporess simply, and the clean work cann't be done in the unload processor
or the wsgifunc can't get header and status from web.ctx. I moved the clean work before the return express of wsgifunc in application.py, it seems to be work fine for me now, any other good idea for the BUGFIX? please tell use an 'official way'
.

2009/1/5 Alva Yi <alv...@gmail.com>

[Alva Yi]

BTW, I am using the GIT version, I reviewed back to the released version 0.31, and it's fine, I currently change to the stable version 0.31 instead of GIT version.

2009/1/5 Alva Yi <alv...@gmail.com>

[Anand Chitipothu]

> it's provied to be a BUG here. I think I fixed this problem.

Sorry, that return came in by accident. I removed it now.

> this bug cann't be fixed by remove the return exporess simply, and the clean
> work cann't be done in the unload processor
> or the wsgifunc can't get header and status from web.ctx.

why?

> I moved the clean
> work before the return express of wsgifunc in application.py, it seems to be
> work fine for me now, any other good idea for the BUGFIX?

That won't work if your GET/POST method is a generator.

[Anand Chitipothu]

>> this bug cann't be fixed by remove the return exporess simply, and the clean
>> work cann't be done in the unload processor
>> or the wsgifunc can't get header and status from web.ctx.

I noticed the problem now.

[Anand Chitipothu]

>> this bug cann't be fixed by remove the return exporess simply, and the clean
>> work cann't be done in the unload processor
>> or the wsgifunc can't get header and status from web.ctx.

It is fixed now.

http://github.com/webpy/webpy/commit/7f83ec476c3ca19f7676b35ab57c61df28be157d

[Alva Yi]

Thanks a lot for your work!

2009/1/7 Anand Chitipothu <anand...@gmail.com>