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

[Erik Bray]

On Tue, Dec 20, 2016 at 9:26 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 20 December 2016 at 00:53, Erik Bray <erik.m.bray at gmail.com> wrote:
>>
>> On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray <erik.m.bray at gmail.com> wrote:
>> >> Likewise - we know the status quo isn't right, and the proposed change
>> >> addresses that. In reviewing the patch on the tracker, the one downside
>> >> I've
>> >> found is that due to "pthread_key_t" being an opaque type with no
>> >> defined
>> >> sentinel, the consuming code in _tracemalloc.c and pystate.c needed to
>> >> add
>> >> separate boolean flag variables to track whether or not the key had
>> >> been
>> >> created. (The pthread examples at
>> >>
>> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_key_create.html
>> >> use pthread_once for a similar effect)
>> >>
>> >> I don't see any obvious way around that either, as even using a small
>> >> struct
>> >> for native pthread TLS keys would still face the problem of how to
>> >> initialise the pthread_key_t field.
>> >
>> > Hmm...fair point that it's not pretty.  One way around it, albeit
>> > requiring more work/complexity, would be to extend this proposal to
>> > add a new function analogous to pthread_once--say--PyThread_call_once,
>> > and an associated Py_once_flag_t
>>
>> Oops--fat-fingered a 'send' command before I finished.
>>
>> So  workaround would be to add a PyThread_call_once function,
>> analogous to pthread_once.  Yet another interface one needs to
>> implement for a native thread implementation, but not too hard either.
>> For pthreads there's already an obvious analogue that can be wrapped
>> directly.  For other platforms that don't have a direct analogue a
>> (naive) implementation is still fairly simple: All you need in
>> Py_once_flag_t is a boolean flag with an associated mutex, and a
>> sentinel value analogous to PTHREAD_ONCE_INIT.
>
>
> 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).
>
> 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.
>
> (I'd also be happy to volunteer as BDFL-Delegate, since I'm already
> reviewing the patch on the tracker)

Okay, thanks.  I will work on a PR to the PEPs repo, and update the
proposal to add the PyThread_call_once idea, which some prescription
for how it should be used.  Of course, an updated patch will have to
follow as well.

This is probably an implementation detail, but ISTM that even with
PyThread_call_once, it will be necessary to reset any used once_flags
manually in PyOS_AfterFork, essentially for the same reason the
autoTLSkey is reset there currently...

Erik