2016-12-17 18:35 GMT+09:00 Stephen J. Turnbull <turnbull.stephen.fw@u. tsukuba.ac.jp>:
I don't understand this. I assume that there are no such platforms supported at present. I would think that when such a platform becomes supported, code supporting "key" functions becomes unsupportable without #ifdefs on that platform, at least directly. So you should either (1) raise UnimplementedError, or (2) provide the API as a wrapper over the new API by making the integer keys indexes into a table of TSS'es, or some such device. I don't understand how (3) "make it a no-op" can be implemented for PyThread_create_key -- return 0 or -1? That would only work if there's a failure return status like 0 or -1, and it seems really dangerous to me since in general a lot of code doesn't check status even though it should. Even for code checking the status, the error message will be suboptimal ("creation failed" vs. "unimplemented").
PyThread_create_key has required user to check the return value since when key creation fails, returns -1 instead of valid key value. Therefore, my patch changes PyThread_create_key that always return -1 on platforms that cannot cast key to int safely and current API never return valid key value to these platforms. Its advantage to not change function specifications and no effect on supported platforms. Hence, this is reason that doesn't raise any exception on the API. (2) of ideas can enable current API on specific-platforms. If it's simple, I'd have liked to select it. However, work that brings current API using native TLS to specific-platforms brings duplication implementation that manages keys, and it's ugly (same reason for Erik's draft, the last item of Rejected Ideas). Thus, I gave up to keep feature and decided to implement "no-op", delegate error handling to API users. Kind regards, Masayuki