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 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 back up this claim
> but I don't think that is the case. I believe a new thread is being 
> created for each request, hence anything thread local will be gc'd at some 
> point.
>
> On Monday, June 17, 2013 6:43:06 PM UTC+8, bmurr wrote:
>>
>> 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 Saturday, June 15, 2013 1:47:25 AM UTC+1, timh wrote:
>>>
>>> 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 :
>>>> http://stackoverflow.com/questions/16966365/in-python-does-dummythread-uniquely-identify-the-current-thread
>>>> ). 
>>>> Using threading.currentThread() with a thread-local storage approach 
>>>> got rid of my immediate problem, but raised an issue that I'm not sure 
>>>> about :
>>>>
>>>> The threads AppEngine creates are outside of threading.py's control, so 
>>>> Python creates these immortal DummyThread objects to represent them when 
>>>> you call threading.currentThread.
>>>>
>>>> My thinking on this was that even if DummyThread objects never die and 
>>>> thus create a memory leak, AppEngine probably doesn't create enough 
>>>> threads 
>>>> and our application is updated frequently enough (once per week, on 
>>>> average), that the number of DummyThreads will be unlikely to grow beyond 
>>>> a 
>>>> certain point and thus any memory leak resulting from DummyThreads will be 
>>>> insignificant.
>>>>
>>>> I'm really not sure whether I'm in for a world of hurt eventually here 
>>>> or whether I should be ok. I'd love to hear some opinions/comments on why 
>>>> this is a good/bad idea, or maybe some suggestions of an alternate 
>>>> approach.
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to