Message205161
| Author |
neologix |
| Recipients |
Arfrever, grahamd, kristjan.jonsson, neologix, pitrou, tim.peters, vstinner |
| Date |
2013年12月03日.21:52:17 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAH_1eM027V4vkV33YVUDo4VWrgmREOxSKLMf3cb5=cbbG=te-g@mail.gmail.com> |
| In-reply-to |
<1386106223.83.0.856117010943.issue19787@psf.upfronthosting.co.za> |
| Content |
> 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() fixed in #10517.
>
> When it comes to threads and fork, I trust neologix because he knows them better than me and he wrote "AFAICT, there's no link".
It's unrelated, but I don't know if changing the current semantics
could break some code, especially involving subinterpreters: that's
why i'd like to have it tested.
But the current behavior is *really* a pain: not having
PyThread_set_key(key, value)
assert(PyThread_get_key(key) == value)
sounds really wrong. |
|