Antoine Pitrou added the comment: > 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 attributes. 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 disproportionate. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18808> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
