This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Tamas.K, csernazs, grahamd, jcea, ncoghlan, neologix, pitrou, python-dev, tim.peters
Date 2013-09-04.15:07:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> 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).

Well... perhaps I'm being too perfectionist, but I don't want Python
to be crashable merely by manipulating a Thread object's private
If I add some check code, it will quickly become more complicated than
the current weakref version, which works by design :-)

> 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).

Yeah, the overall concern is a bit obscure, but still: right now, if
you use threads inside a subinterpreter, your code can work or crash
depending on subtle timing conditions (where "crash" doesn't even mean
"raise an exception" but "abort the whole process"). So I think it's
worth trying to fix, even though the complication can look a bit
Date User Action Args
2013-09-04 15:07:43pitrousetrecipients: + pitrou, tim.peters, jcea, csernazs, ncoghlan, grahamd, neologix, python-dev, Tamas.K
2013-09-04 15:07:42pitroulinkissue18808 messages
2013-09-04 15:07:42pitroucreate