On 20 December 2016 at 00:53, Erik Bray <erik.m.b...@gmail.com> wrote:
> On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray <erik.m.b...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
