Is middleware in Django thread-safe?
django, multithreading, python, thread-safety, webserver
Solution
The point, as I note in that article, is that the middleware is instantiated once per process. In most methods of deploying Django, a process lasts for multiple requests. Note that you never instantiate the middleware object yourself: Django takes care of that. That's a clue that it's being done outside the request/response cycle.
The extra object I used there is being instantiated within the process_response method. So, as soon as that method returns, the new object goes out of scope and is destroyed, and there are no thread-safety issues.
Generally speaking, the only objects you have to worry about thread-safety on are those you instantiate at module or class level rather than inside a function/method, and those you don't instantiate yourself, like the middleware here. And even there, requests are explicitly an exception: you can count on those being per-request (naturally).
Problem
Recently I've read this article: http://blog.roseman.org.uk/2010/02/01/middleware-post-processing-django-gotcha/ I don't understand, why does the solution described there work? Why does instantiating separate objects make data chunk thread-safe? I have two guesses: - Django explicitly holds middleware objects in shared memory, and do not do this for other objects, so other objects are thread-safe. - In second example, in article, lifetime of thread-safety-critical data is much less that in first example, so probably, thread-unsafe operations just have no time to occur. There is also issues with thread-safety in Django templates. My question is - how to guess when Django thread-safe and where its not? is there any logic in it or conventions? Another question - I know that request object is thread safe - it is clear, that it wouldn't be safe, web-sites built with Django would be not able to operate, but what exactly makes it thread-safe?