On Mon, Dec 19, 2016 at 3:45 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > On Mon, Dec 19, 2016 at 1:11 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 17 December 2016 at 03:51, Antoine Pitrou <solip...@pitrou.net> wrote: >>> >>> On Fri, 16 Dec 2016 13:07:46 +0100 >>> Erik Bray <erik.m.b...@gmail.com> wrote: >>> > Greetings all, >>> > >>> > I wanted to bring attention to an issue that's been languishing on the >>> > bug tracker since last year, which I think would best be addressed by >>> > changes to CPython's C-API. The original issue is at >>> > http://bugs.python.org/issue25658, but I have made an effort below in >>> > a sort of proto-PEP to summarize the problem and the proposed >>> > solution. >>> > >>> > I haven't written this up in the proper PEP format because I want to >>> > see if the idea has some broader support first, and it's also not >>> > clear to me whether C-API changes (especially to undocumented APIs) >>> > even require their own PEP. >>> >>> This is a nice detailed write-up and I'm in favour of the proposal. >> >> >> 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. Best, Erik _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
