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?
K
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
