(original) (raw)

Hello there.

Yesterday I posted a feature request, http://bugs.python.org/issue3582, along with a patch.

It provides platform specifict TLS functions on windows.

Implementing it I came across the strange semantics of PyThread\_set\_key\_value(). �If a value has been set previously, it will ignore the set.

This is most unusual, and I had to make two TLS calls in the NT version to emulate this behaviour.

This behaviour is mentioned in pystate.c:

�� The only situation where you can legitimately have more than one

�� thread state for an OS level thread is when there are multiple

�� interpreters, when:

�� a) You shouldn't really be using the PyGILState\_ APIs anyway,

�� and:

�� b) The slightly odd way PyThread\_set\_key\_value works (see

�� comments by its implementation) means that the first thread

�� state created for that given OS level thread will "win",

�� which seems reasonable behaviour.

�� \*/

Now, this seems to be the only place where this is required, but I fail to see how even in

this scenario it makes sense.� As a) code says, you shouldn’t be using the GIL api anyway, and

it will undoubtebly create problems elsewhere if sticking the thread state into TLS fails silently.

Changing this odd behaviour of PyThread\_set\_key\_value () is trivial and would make it easier to use native TLS functions on other platforms.� Any thoughts?