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

[Nick Coghlan]

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)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161220/fa410309/attachment.html>