<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-12-31 16:42 GMT+09:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On 31 December 2016 at 08:24, Masayuki YAMAMOTO <span dir="ltr"><<a href="mailto:ma3yuki.8mamo10@gmail.com" target="_blank">ma3yuki.8mamo10@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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 :)<br><br>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.<br></div></div></blockquote><div><br></div></span><div>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.<br><br>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.<br></div></div></div></div></blockquote><div><br>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.<br><br></div><div>Best regards,<br></div><div>Masayuki<br></div></div></div></div>