New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
threading.local doesn't free attrs when assigning thread exits #46176
Comments
threading.local doesn't free attributes assigned to a local() instance Per discussion with Crys and arkanes in #python, this may be an issue This appears to affect both thread._local and _threading_local.py |
I've added a test in r60075. It shows that threading.local cleans up thread local data except for the |
re: r60075 : I'm unclear - is this intentional behavior? Adding a |
On the opposite, simply evaluating Weird? I found that in threadmodule.c, the local object has a Maybe localobject could be rewritten with no self->dict at all. Or make |
Here is a patch that removes the member localobject->dict. |
see also bpo-3710 |
I like Amaury's patch, it gets rid of what seems like an existing gross I believe it may also fix bpo-3710 by getting rid of the unnecessary Could someone else please review this? threading_local.patch is available for review here: |
I like this patch, too! I think it's a much cleaner way of implementing I've attached a test program that shows the issue. |
Good catch, Ben! The generic setattr/getattr functions don't work as expected when the My patch fixes the behavior. However it might be a better idea to make |
Christian, Your patch works for me -- thanks!! I made a slight modification to your patch to allow "del" to work, I agree that allowing subclassing makes thread._local harder to get |
this is ready for more review at http://codereview.appspot.com/3641 |
The patch is basically fine with me. While reviewing it I've found out |
With the patch, subclasses of threading.local seem to have an empty import threading
class MyLocal(threading.local):
pass
l = MyLocal()
l.x = 2
l.__dict__ # returns {} Maybe __dict__ should be special-cased in local_getattro()? |
Amaury Forgeot d'Arc wrote:
With the patch it's also no longer possible to get a list of attribute Christian |
i won't have time to work on this for several days but i will happily feel free to steal the issue from me. |
If Christian's analysis is right, and memory is released except for the Also (unless I misinterpret the issue), it seems that we have made many Tentatively lowering the priority to high. |
Agreed, this is fine for a bugfix point release. I was initially concerned about the Modules/threadmodule.c struct |
Is any of the patches believed to be ready? |
Reconsidering: I think the "needs review" keyword should only be applied |
Since no specific patch was proposed for 2.5.3, I'm untargetting it for 2.5. |
The original patch won't apply anymore, because of changes in the thread._local implementation. Instead, here is a new patch, which also adds tests for the __dict__ behaviour, and two new private API functions: _PyObject_Generic{Get,Set}AttrWithDict. These are the same as PyObject_Generic{Get,Set}Attr, except that it allows to pass the instance dict instead of letting the function discover it. |
It should be noted that the original reason for this issue is already gone in SVN (as part of the reimplementation alluded to above), but the timing fragility is still there since there can be a thread switch between the moment the "dict" member is set and the moment it is actually used. Hence the patch I've posted, to get rid of the "dict" member and instead handle lookups of the __dict__ attributes ourselves. |
your updated patch looks good to me. i've posted it here for easy review if anyone else wants to take a look: |
Thank you Gregory. I've committed the patch in r84344 (py3k), r84345 (3.1) and r84346 (2.7). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: