[issue11866] race condition in threading._newname()

R. David Murray added the comment: I committed a version of this that uses Raymond's suggestion and also makes sure that the first thread is named Thread-1 as it has been in the past (there was a test failure without that fix, but I also think it makes sense for it to be Thread-1 since one wou

[issue11866] race condition in threading._newname()

Roundup Robot added the comment: New changeset a6b4add67168 by R David Murray in branch '2.7': #11866: Eliminate race condition in the computation of names for new threads. https://hg.python.org/cpython/rev/a6b4add67168 New changeset a6906b9e21d5 by R David Murray in branch '3.4': #11866: Elimin

[issue11866] race condition in threading._newname()

Antoine Pitrou added the comment: With or without Raymond's suggested change, "global _counter" is not necessary anymore. Note that this fix only works on implementations where itertools.count().next is atomic. -- ___ Python tracker

[issue11866] race condition in threading._newname()

Changes by Charles-François Natali : -- stage: -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11866] race condition in threading._newname()

Raymond Hettinger added the comment: I think the patch is correct. FWIW, my style is to prebind the next method, making the counter completely self-contained (like a closure): +_counter = itertools.count().next def _newname(template="Thread-%d"): global _counter -_counter = _counter

[issue11866] race condition in threading._newname()

Peter Saveliev added the comment: counter.next() is a C routine and it is atomic from Python's point of view — if I understand right. The test shows that original threading.py leads to a (rare) race here, while with counter object there is no race condition. -- _

[issue11866] race condition in threading._newname()

Amaury Forgeot d'Arc added the comment: Are you sure that counter.next() cannot release the GIL? Remember that any DECREF can trigger the garbage collector and execute arbitrary code... -- nosy: +amaury.forgeotdarc ___ Python tracker

[issue11866] race condition in threading._newname()

Peter Saveliev added the comment: Any news? I hope, the change is trivial enough… -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue11866] race condition in threading._newname()

Peter Saveliev added the comment: Ok, patch attached. Patch made for Python: 2.6 Tested Python versions: 2.6, 2.7 -- keywords: +patch versions: +Python 2.6 Added file: http://bugs.python.org/file21866/newname_race_fix.patch ___ Python tracker

[issue11866] race condition in threading._newname()

Antoine Pitrou added the comment: Do you want to provide a patch? -- components: +Library (Lib) -Extension Modules nosy: +pitrou versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6 ___ Python tracker

[issue11866] race condition in threading._newname()

New submission from Peter Saveliev : The _newname() function has no locking. It is called from the new thread constructor. Such constructor is executed within parent thread. So, when several threads create new threads simultaneously, there can be race condition, leading to the same name for tw