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. 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/
