2016-12-31 16:42 GMT+09:00 Nick Coghlan <ncoghlan@gmail.com>:
On 31 December 2016 at 08:24, Masayuki YAMAMOTO <ma3yuki.8mamo10@gmail.com
wrote:
I have read the discussion and I'm sure that use structure as Py_tss_t instead of platform-specific data type. Just as Steve said that Py_tss_t should be genuinely treated as an opaque type, the key state checking should provide macros or inline functions with name like PyThread_tss_is_created. Well, I'd resolve the specification a bit more :)
If PyThread_tss_create is called with the created key, it is no-op but which the function should succeed or fail? In my opinion, It is better to return a failure because it is a high possibility that the code is incorrect for multiple callings of PyThread_tss_create for One key.
That's not what we currently do for the EnsureGIL autoTLS key and the tracemalloc key though - the reentrant key creation is part of "create-if-needed" flows where the key creation is silently skipped if the key already exists.
Changing that would require some further research into how we ended up with the current approach, while carrying it over into the new API design would be the default option.
Yes, as you pointed out, my suggestion changes API semantics and not inherit "create-if-needed". I confirmed again codes...current approach has enough to work and I've not found strong benefit to change the semantics. So I agree with you and withdraw my suggestion. Well, I'm going to update patch based on the result. Best regards, Masayuki