Home Original page

[Python-ideas] New PyThread_tss_ C-API for CPython

Masayuki YAMAMOTO ma3yuki.8mamo10 at gmail.com
Sat Jan 7 03:37:09 EST 2017 
2016-12-31 16:42 GMT+09:00 Nick Coghlan <ncoghlan at gmail.com>:

> On 31 December 2016 at 08:24, Masayuki YAMAMOTO <ma3yuki.8mamo10 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170107/55ff9284/attachment-0001.html>
More information about the Python-ideas mailing list