[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Roundup Robot added the comment: New changeset 46393019b650 by Victor Stinner in branch 'default': Close #19787: PyThread_set_key_value() now always set the value. In Python 3.3, http://hg.python.org/cpython/rev/46393019b650 -- nosy: +python-dev resolution: -> fixed stage: -> committed

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Antoine Pitrou added the comment: On jeu., 2013-12-12 at 21:59 +, STINNER Victor wrote: > So are you ok to apply the bugfix in Python 3.4? I'm ok. -- ___ Python tracker ___

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: If I understand correctly, there is probably only one application (mod_python) which might be broken by fix_set_key_value.patch. If an application is broken by fix_set_key_value.patch, it can get the old behaviour using: int PyThread_set_key_value33(int key,

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Changes by STINNER Victor : -- versions: +Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Kristján Valur Jónsson added the comment: +1 Why don't we just fix this and see where the chips fall? -- ___ Python tracker ___ ___ Py

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Charles-François Natali added the comment: > STINNER Victor added the comment: > > Kristján> Only that issue #10517 mentions reasons to keep the old behavior, > specifically http://bugs.python.org/issue10517#msg134573 (...) > > @Kristján: The behaviour of PyThread_set_key() discussed in this iss

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: Kristján> Only that issue #10517 mentions reasons to keep the old behavior, specifically http://bugs.python.org/issue10517#msg134573 (...) @Kristján: The behaviour of PyThread_set_key() discussed in this issue is unrelated to the pthread bug related to fork()

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Kristján Valur Jónsson added the comment: Only that issue #10517 mentions reasons to keep the old behavior, specifically http://bugs.python.org/issue10517#msg134573 I don't know if any of the old arguments are still valid, but I suggested changing this years ago and there was always some object

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Charles-François Natali added the comment: AFAICT, there's no link (FWIW I wrote the patch for #10517, then the fix for threads created outside of Python calling into a subinterpreter - issue #13156). Actually, this "fix" would have avoided the regression in issue #13156. But since it's tricky, I

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: > Please see the rather long discussion in http://bugs.python.org/issue10517 > There were issues having to do with fork. Python has now a _PyGILState_Reinit() function. I don't see how fix_set_key_value.patch would make the situation worse. What is the link be

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Kristján Valur Jónsson added the comment: Please see the rather long discussion in http://bugs.python.org/issue10517 There were issues having to do with fork. -- ___ Python tracker _

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Kristján Valur Jónsson added the comment: But yes, I'd like to see this behave like normal. -- ___ Python tracker ___ ___ Python-bugs-

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: Attached patch fix PyThread_set_key_value() instead of adding a new function. I prefer fix_set_key_value.patch instead of pythread_set_key_value.patch because I feel bad of keeping a buggy function and having to decide between a correct and a buggy version of

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Kristján Valur Jónsson added the comment: See also issue #10517 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Kristján Valur Jónsson added the comment: Deja vu, this has come up before. I wanted to change this because native TLS implementation become awkward. https://mail.python.org/pipermail/python-dev/2008-August/081847.html -- ___ Python tracker

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: > The question is why does it behave this way in the first place? > Maybe for sub-interpreters? The code is old. I don't think that it's related to subinterpreter. PyThread_set_key_value() is used in _PyGILState_Init() and PyGILState_Ensure(), but its behaviou

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Charles-François Natali added the comment: > Antoine Pitrou added the comment: > > Calling it _PyThread_set_key_value is prone to confusion. > Ideally we would fix PyThread_set_key_value's behaviour. Are there users of > the function outside from CPython? The question is why does it behave this

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: 2013/11/28 Antoine Pitrou : > Calling it _PyThread_set_key_value is prone to confusion. > Ideally we would fix PyThread_set_key_value's behaviour. Are there users of > the function outside from CPython? PyThread_set_key_value() is defined and used in CPython, a

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Antoine Pitrou added the comment: Calling it _PyThread_set_key_value is prone to confusion. Ideally we would fix PyThread_set_key_value's behaviour. Are there users of the function outside from CPython? -- ___ Python tracker

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: I ran test_tracemalloc on Linux and Windows and the test passed successfully. It should probably be better to split the patch in two parts if the idea of changing Python/thread* files is accepted. (But initially, the issue comes from the tracemalloc module.)

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: Oh, here is in interesting commit: --- changeset: 33705:891042c94aed branch: legacy-trunk user:Tim Peters date:Sat Oct 09 22:33:09 2004 + files: Python/thread.c description: Document the results of painful reverse-engineering of

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

Changes by Antoine Pitrou : -- type: -> enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mai

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

STINNER Victor added the comment: Extract of Modules/_tracemalloc.c: static void set_reentrant(int reentrant) { assert(reentrant == 0 || reentrant == 1); if (reentrant) { assert(PyThread_get_key_value(tracemalloc_reentrant_key) == NULL); PyThread_set_key_value(tracemalloc

[issue19787] tracemalloc: set_reentrant() should not have to call PyThread_delete_key()

New submission from STINNER Victor: The tracemalloc module uses PyThread_set_key_value() to store an flag in the Thread Local Storage. The problem is that it is not possible to call the function twice with two different values. If PyThread_set_key_value() is called with a non-NULL pointer, the