This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients bquinlan, dmalcolm, jnoller, kristjan.jonsson, lukasz.langa, neologix, pitrou, sandro.tosi, ysj.ray
Date 2011-04-26.16:26:18
SpamBayes Score 1.3162249e-11
Marked as misclassified No
Message-id <1303835169.3518.19.camel@localhost.localdomain>
In-reply-to <>
> > How about deleting the mapping (pthread_key_delete) and recreating it
> > from scratch, then?
> Sounds good.
> So the idea would be to retrieve the current thread's tstate, destroy
> the current autoTLSkey, re-create it, and re-associate the current
> tstate to this new key. I just did a quick test on RHEL4 and it works.
> PyThread_ReinitTLS looks like a good candidate for that, but it's the
> same problem, autoTLSkey scope is limited to pystates.c (and I'm not
> sure that the tstate should be exposed to platform thread
> implementations).
> There's also PyEval_ReinitThreads in ceval.c, exposing the autoTLSkey
> would make more sense (and it already knows about tstate, of course).
> Where would you put it?

You could add a new _PyGILState_ReInit() function and call it from
PyOS_AfterFork() or PyEval_ReInitThreads().

(perhaps you also need to add a TLS-destroying function to thread.c, I
haven't looked)
Date User Action Args
2011-04-26 16:26:19pitrousetrecipients: + pitrou, bquinlan, kristjan.jonsson, jnoller, dmalcolm, sandro.tosi, ysj.ray, neologix, lukasz.langa
2011-04-26 16:26:18pitroulinkissue10517 messages
2011-04-26 16:26:18pitroucreate