Message196672
| Author |
tim.peters |
| Recipients |
Tamas.K, grahamd, jcea, ncoghlan, neologix, pitrou, python-dev, tim.peters |
| Date |
2013年08月31日.21:01:24 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1377982884.97.0.741244299739.issue18808@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I'm getting a headache now - LOL ;-) Thanks for the explanation!
What I still don't understand: the new lock is an internal implementation detail. How would it gain a weakref with a callback? Users aren't going to mess with this lock, and if you want to stop Python maintainers from giving it a weakref with a callback, simply say they shouldn't do that (in the code comments) - you could even add code verifying it doesn't have any weakrefs outstanding (although that would likely be a waste of time and code: no maintainer is going to _want_ to make a weakref to it, let alone a weakref with a callback).
My concern is the bulk and obscurity of this code, all to plug such a minor hole. I call it "minor" because it's been reported once in the history of the project, and Tamas wormed around it with a 1-liner (added a sleep).
Granted, it's much harder to fix "for real" and when most of the interpreter has been destroyed ;-) |
|