<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 December 2016 at 00:53, Erik Bray <span dir="ltr"><<a href="mailto:erik.m.bray@gmail.com" target="_blank">erik.m.bray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray <<a href="mailto:erik.m.bray@gmail.com">erik.m.bray@gmail.com</a>> wrote:<br>>> Likewise - we know the status quo isn't right, and the proposed change<br>
>> addresses that. In reviewing the patch on the tracker, the one downside I've<br>
>> found is that due to "pthread_key_t" being an opaque type with no defined<br>
>> sentinel, the consuming code in _tracemalloc.c and pystate.c needed to add<br>
>> separate boolean flag variables to track whether or not the key had been<br>
>> created. (The pthread examples at<br>
>> <a href="http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html" rel="noreferrer" target="_blank">http://pubs.opengroup.org/<wbr>onlinepubs/009695399/<wbr>functions/pthread_key_create.<wbr>html</a><br>
>> use pthread_once for a similar effect)<br>
>><br>
>> I don't see any obvious way around that either, as even using a small struct<br>
>> for native pthread TLS keys would still face the problem of how to<br>
>> initialise the pthread_key_t field.<br>
><br>
> Hmm...fair point that it's not pretty.  One way around it, albeit<br>
> requiring more work/complexity, would be to extend this proposal to<br>
> add a new function analogous to pthread_once--say--PyThread_<wbr>call_once,<br>
> and an associated Py_once_flag_t<br>
<br>
</div></div>Oops--fat-fingered a 'send' command before I finished.<br>
<br>
So  workaround would be to add a PyThread_call_once function,<br>
analogous to pthread_once.  Yet another interface one needs to<br>
implement for a native thread implementation, but not too hard either.<br>
For pthreads there's already an obvious analogue that can be wrapped<br>
directly.  For other platforms that don't have a direct analogue a<br>
(naive) implementation is still fairly simple: All you need in<br>
Py_once_flag_t is a boolean flag with an associated mutex, and a<br>
sentinel value analogous to PTHREAD_ONCE_INIT.<br></blockquote><div><br></div></div>Yeah, I think I'd prefer that - it aligns nicely with the way pthreads are defined, and means we can be more prescriptive about how to use the new API correctly for key declarations (we're currently a bit vague about exactly how to handle that in the current TLS API).<br><br></div><div class="gmail_extra">With that addition, I think it will be worth turning your initial post here into a PR to the peps repo, though - not to resolve any particular controversy, but rather as an easier to find reference for the design rationale than a mailing list thread or a tracker issue.<br><br></div><div class="gmail_extra">(I'd also be happy to volunteer as BDFL-Delegate, since I'm already reviewing the patch on the tracker)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>