Ok, that makes sense, and if you haven't seen any memory leaks with it, it
sounds like threading.local is probably the right way to go.
Thanks for the discussion, it's been very helpful!
On Monday, June 17, 2013 3:56:12 PM UTC+1, timh wrote:
Thread local is specific to a single request. I
You're right, looks like threading.local also fixes the concurrency problem.
But surely if Python can't tell when an alien thread gets joined, then the
variables used in threading.local will never go out of scope and get
garbage collected? Which leads to a memory leak, like before?
On
Thread local is specific to a single request. I have not seen any evidence
of memory leaks using it. (I have thread.local in heavy use on a number of
projects).
I think you are assuming there is a thread pool, and threads and therefore
thread.local is re-used. I don't have any evidence to
Why do you need to call currentThread() to create thread local storage?
You can just create threadlocal storage.
On Friday, June 14, 2013 8:15:25 PM UTC+8, bmurr wrote:
After switching threadsafe to true in my app.yaml, I had some concurrency
issues (detailed in this SO question, here :
