Since mod_wsgi was written, what happened with thread local data
between requests handled by same thread has differed depending on
whether application was being run in the first/main interpreter, ie.,
where application group was '%{GLOBAL}', or a sub interpreter.When the first/main interpreter was used by mod_wsgi, the behaviour was the same as command line Python, and thus any WSGI server implemented as pure Python. That is, thread local data stored within threading.local() dictionary persisted between requests handled by the same thread from the server thread pool. For other sub interpreters created by mod_wsgi, any thread local data was deleted at the end of a request and didn't persist through to subsequent requests handled by the same thread. This meant that thread local data couldn't be reliably used as a means of caching data specific to a thread that should last for lifetime of a process. Any such data would need to have been recreated on each request, or stored as normal global module data with suitable thread mutexing to protect access/updates. If you follow all that, be advised that in this respect, latest changes in mod_wsgi 3.0 subversion trunk make sub interpreters behave like first/main interpreter and thus how things would behave if running application under a pure Python WSGI server. So, if your application was making use of thread local data as a process long caching mechanism, you should see things behaviour in a more conventional manner. Because of the nature of the changes, if using mod_wsgi 3.0 subversion trunk, keep an eye out for any unexpected behaviour/bugs resulting from the change and let me know. Testing seems to indicate it works properly, but since getting this right was tricky, there could still be gremlins in there. :-) The issue for this problem was: http://code.google.com/p/modwsgi/issues/detail?id=120 The changes were committed at revision 1213:1214. FWIW, mod_wsgi has been implemented the way it was because it followed the pattern that mod_python used for handling of thread state objects, namely creating them at start of request and destroying them at the end of the request. The mod_wsgi code now correctly caches the thread state objects between requests made by same thread against the same interpreter and another one of mod_python's incorrect behaviours has been eliminated. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
