Right. Platforms that have a defined invalid value don't need the struct, and so they can define the type differently. It just means we also need to provide a macro for testing whether it's been created or not, and users should genuinely treat the value as opaque. Cheers, Steve Top-posted from my Windows Phone -----Original Message----- From: "Masayuki YAMAMOTO" <ma3yuki.8mamo10@gmail.com> Sent: ‎12/‎23/‎2016 16:34 To: "Erik Bray" <erik.m.bray@gmail.com> Cc: "python-ideas@python.org" <python-ideas@python.org> Subject: Re: [Python-ideas] New PyThread_tss_ C-API for CPython 2016-12-21 19:01 GMT+09:00 Erik Bray <erik.m.bray@gmail.com>: On Wed, Dec 21, 2016 at 2:10 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Ouch, I'd missed that, and I agree it's not a negligible implementation detail - there are definitely applications embedding CPython out there that rely on being able to run multiple Initialize/Finalize cycles in the same process and have everything "just work". It also means using the "PyThread_*" prefix for the initialisation tracking aspect would be misleading, since the life cycle details are:

1. Create the key for the first time if it has never been previously set in the process 2. Destroy and reinit if Py_Finalize gets called 3. Destroy and reinit if a new subprocess is forked

It also means we can't use pthread_once even in the pthread TLS implementation, since it doesn't provide those semantics.

So I see two main alternatives here.

Option 1: Modify the proposed PyThread_tss_create and PyThread_tss_delete APIs to accept a "bool *init_flag" pointer in addition to their current arguments.

If *init_flag is true, then PyThread_tss_create is a no-op, otherwise it sets the flag to true after creating the key. If *init_flag is false, then PyThread_tss_delete is a no-op, otherwise it sets the flag to false after deleting the key.

Option 2: Similar to option 1, but using a custom type alias, rather than using a C99 bool directly

The closest API we have to these semantics at the moment would be PyGILState_Ensure, so the following API naming might work for option 2:

Py_ensure_t Py_ENSURE_NEEDS_INIT Py_ENSURE_INITIALIZED

Respectively, these would just be aliases for bool, false, and true.

And then modify the proposed PyThread_tss_create and PyThread_tss_delete APIs to accept a "Py_ensure_t *init_flag" in addition to their current arguments.

That all sounds good--between the two option 2 looks a bit more explicit. Though what about this? Rather than adding another type, the original proposal could be changed slightly so that Py_tss_t *is* partially defined as a struct consisting of a bool, with whatever the native TLS key is. E.g. typedef struct { bool init_flag; #if defined(_POSIX_THREADS) pthreat_key_t key; #elif defined (NT_THREADS) DWORD key; /* etc... */ } Py_tss_t; Then it's just taking Masayuki's original patch, with the global bool variables, and formalizing that by combining the initialized flag with the key, and requiring the semantics you described above for PyThread_tss_create/delete. For Python's purposes it seems like this might be good enough, with the more general purpose pthread_once-like functionality not required. Best, Erik Above mentioned, In currently TLS API, the thread key uses -1 as defined invalid value. If new TLS API inherits the specifications that the key requires defined invalid value, putting key and flag into one structure seems correct as semantics. In this case, I think TLS API should supply the defined invalid value (like PTHREAD_ONCE_INIT) to API users. Moreover, the structure has an opportunity to assert that the thread key type is the opaque using field name. I think to the suggestion that has effect to improve the understandability of the API because good field name can give that reading and writing to the key seems to be incorrect (even if API users don't read the precautionary statement). Have a nice holiday! Masayuki