Thread local storage and Python sub interpreters.
Graham Dumpleton
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