> Antoine, I wonder if we can restore PyThread_set_key_value to behave
> like a canonical TLS api function (always setting) but fix the cases
> that want to "set if it has not already been set" like the cases you
> mention.
> It is very unorthodox to have such "only set if it hasn't been set
> before" built into your only TLS function.  This wart on python's TLS
> api has bugged me for yearsand it would be cool to fix it.

Well, these functions are supposed to be private so, while I agree their
behaviour is a bit unusual, I'm not sure there's any point to "fix" them
if it shifts the burden of reproducing the old behaviour on another part
of our code.

> The init functions (that internally call the python TLS apis) could
> simply do a TLS get explicitly themselves, to make it explicit and
> clear that they _want_ to use any pre-existing tls value.

Granted.

> Of course, that won't fix _this_ problem (which is that the main
> thread's tls value gets inherited on fork).  The right way to do that
> is to explicitly clearthe main thread's TLS value after fork...

The main thread is fine, actually, it's the other (disappeared) threads
which cause this problem when the same TID is re-used.