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

[Nick Coghlan]

On 17 December 2016 at 03:51, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Fri, 16 Dec 2016 13:07:46 +0100
> Erik Bray <erik.m.bray at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161219/08bf098c/attachment.html>