2016-12-31 16:42 GMT+09:00 Nick Coghlan <ncogh...@gmail.com>: > On 31 December 2016 at 08:24, Masayuki YAMAMOTO <ma3yuki.8mam...@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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
