homepage

> 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 behaviour when the key already exists doesn't matter because these functions only call PyThread_set_key_value() once pr thread. It was probably simpler to implement PyThread_set_key_value() like it is nowadays. When the native TLS support was added, the new functions just mimic the old behaviour.
Code history.
find_key() function has been added at the same time than the PyThreadState structure. set_key_value() was already doing nothing when the key already exists. It looks like set_key_value() was not used.
---
changeset: 5405:b7871ca930ad
branch: legacy-trunk
user: Guido van Rossum <guido@python.org>
date: Mon May 05 20:56:21 1997 +0000
files: Include/Python.h Include/frameobject.h Include/pystate.h Include/pythread.h Include/thread.h Modules/threadmodule.c Objects/frameobject
description:
Massive changes for separate thread state management.
All per-thread globals are moved into a struct which is manipulated
separately.
---
TLS only started to be used in CPython since the following major change:
---
changeset: 28694:a4154dd5939a
branch: legacy-trunk
user: Mark Hammond <mhammond@skippinet.com.au>
date: Sat Apr 19 15:41:53 2003 +0000
files: Include/pystate.h Include/pythread.h Lib/test/test_capi.py Modules/_testcapimodule.c Modules/posixmodule.c Python/ceval.c Python/pystat
description:
New PyGILState_ API - implements pep 311, from patch 684256.
---
Native TLS support is very recent (compared to the first commit):
---
changeset: 64844:8e428b8e7d81
user: Kristján Valur Jónsson <kristjan@ccpgames.com>
date: Mon Sep 20 02:11:49 2010 +0000
files: Python/pystate.c Python/thread_nt.h Python/thread_pthread.h
description:
issue 9786 Native TLS support for pthreads
PyThread_create_key now has a failure mode that the applicatino can detect.
---